微服务防止软件退化

开放-封闭（OCP）原则

• 开放原则：对于功能扩展是开发放的，当需求变化时，可以对功能进行扩展，满足新用户的需求
• 封闭原则：对软件代码的修改是封闭的，在修改软件的同时，不能影响到系统原有的功能

变更步骤

• 不增加新功能的前提下，重构代码，调整代码结构，以适应新功能
• 满足需求，实现新的功能

领域驱动

把软件设计与真实世界对应建立领域模型，在每次变更的时候，先将需求变更还原到领域模型，基于业务进行领域模型的变更。然后，再基于领域模型的变更，指导程序的变更。

单一职责原则

软件系统中每个元素只完成自己职责范围内的事，其它的事情交给别人做，只调用

低耦合，高内聚

高质量的代码

当提出一个需求变更时，为了实现这个变更而修改软件的成本越低，那么软件的质量就越高

不断调整代码，将因同一原因变更而变更的代码放在一起，而不同原因的放到不同的模块和类中，这样当因为这个原因而需要修改代码时，需要修改的都放在这个模块和类中，修改范围小了，维护成本 降低了，质量就自然高了

例如：

• 当“付款”发生变更时，“折扣”是不是一定要变？
• 当“折扣”发生变更时，“付款”是不是一定要变？

领域模型指导设计

服务（Service）

标识在领域对象之外的操作与行为。

接收用户请求和执行某些操作

实体（Entity)

通过一个唯一标识字段来区分真实世界每一个个体的领域对象。可变

值对象

真实世界中一成不变，本质性的事物，如地理位置，币种，行业，职位等。不可变

设计思路

贫血模型

不包含业务逻辑

• 简单易行，充血模型需要添加仓库、工厂组件，对设计和架构能力要求更高
• 更容易应对复杂的业务处理场景

充血模型

各种操作不在“服务”中实现，而是在领域对象中实现

• 保持了领域对象的封装性，使在面临多态、继承等复杂结构时，易于变更。

• 保持了领域模型的原貌，当领域模型随着业务变更时，比较直观映射成程序变更，代码修改起来直接

• 需要更强的设计与协作能力

适用场景

• 充血：领域模型中出现类似继承、多态的情况，需要一些类型或者编码进行转换，更好的需要一些类型或者编码进行转换，聚合代表现实世界中整体和部分的关系
• 贫血：

聚合

体现的是整体和部分的关系

聚合根

聚合关系中，部分封装在整体里面，整体成为外部访问的唯一入口

聚合通常会采用需要一些类型或者编码进行转换完成对数据库的访问

工厂主要的工作是通过装配，创建领域对象，是领域对象生命周期的起点

架构师核心能力

• 能够将业务转换为技术
• 合理利用技术支撑业务

微服务接口规划

• 怎么提供：尽量通过现有接口解决问题
• 接口变更：向前兼容
• 确定修改现有接口：宁可增加新接口也不变更原有接口

数据管理（去中心化）

数据量和用户访问特点，选用不同的存储方案存储数据

• 数据量小但频繁读取
• 数据量大并且高并发写
• 分析业务数据使用

不同维度进行微服务拆分

• 压力模型

  • 高频高并发流量：商品详情页，优惠计算
  • 低频突发流量：秒杀，批量上架

• 服务隔离

  • 热点数据
  • 热点隔离

• 主链路规划

  • 搜索

  • 详情

  • cart

  • 下单

  • 支付

  • 营销计算

  • 服务隔离，流控，异常容错，弹性

• 用户群体：2c 2b 用户端 运营 采购，相同领域，独有场景

• 前后台业务：买家，商家后台，运营后台

微服务无状态化 stateless

有状态：水平扩展乏力

• 上下文依赖：单机session，单机缓存（hash+本地缓存的热点方案）

应用无状态，配置管理有状态

商品中心--->集群A、集群B---> 配置文件A，配置文件B

如何通过接口版本控制实现向后兼容

• RPC接口：`<dubbo:reference id="imooc" version="1.0.2" interface="xxx"/>
• http接口：
  • path
  • header：业务网关---> path

流量整形

服务可用性保障手段

• 令牌桶
• 漏桶

限流+降级

• 网关层/分布式限流
• 限流点
  • 访问频率
  • IP连接数
  • 黑白名单
  • 传输速率
• 资源成本：业务限流
  • 业务网关：Gateway/Zuul
  • 限流组件：sentinel，redis+lua，单机guava

限流：504

降级：前端处理500，后端降级200

EDA事件驱动

• 异步处理
• 跨平台/语言通信
• 应用解耦
• 适可而止
• 最终一致性
• 可靠投递

账务系统

• 卖家支付：会计账目，报表系统，退款流程

业务方不配合（每一个架构问题都是一个以大化小的过程）

以大化小：捕捉支付事件，消费事件

职责领域划分

微服务的数据一致性，base理论

应用视角：用什么语言实现功能

功能视角：who how what

运行视角：where when

举例：商品信息crud（功能），单元化数据分布（运行视角）