微服务演化过程和特点

微服务

单体架构

适合演化早期，业务迭代时逐渐暴露缺点。

• 一个war或者Jar包。

优点

• 业务迭代简单。
  • 应用开发、大规模修改方便。
  • 测试简单。
  • 部署简单。
• 横向扩展无脑。只需要负载均衡多个实例。

缺点

• 业务迭代困难。
  • 内部逻辑复杂度过高，类似脏泥球，冲突多、耦合严重，导致开发、测试缓慢。
• 技术迭代困难。
  • 依赖一套技术栈，使用新技术试错成本高。
• 扩展困难，成本高。
  • 不同硬件的需求集中在同一个实例上，扩展需要满足所有模块的需求。
  • 横向扩展有db连接数等限制。
• 缺乏故障隔离。模块之间可能互相影响。

中心化架构

分布式单体

• ESB（企业服务总线）。
  • 通过技术接口适配接入、数据格式转换、数据裁剪、服务请求路由，解决异构系统之间的交互。
    
  • 使用重量级的SOAP等协议。
• 使用全局数据模型、共享数据库。

优点

• 业务、技术迭代难度降低。
• 扩展方便。可按需扩展。
• 故障隔离。

缺点

• 响应慢。请求需要通过总线，rpc次数翻倍。
• 总线扩展成本高。压力大，需要的硬件带宽等成本很高。
• 总线雪崩隐患。流量高峰时总线单机故障，容易造成更多机器宕机，造成整体不可用。

微服务架构

去中心化

• 使用哑管道打通系统，如同步的REST、异步的消息代理。
• 每个服务有各自的数据库和模型。

优点

• 业务迭代可持续。服务和维护团队小，可持续交付、持续部署。
  • 每个服务小，高内聚，容易开发、测试、部署。
  • 维护团队小，之间松散耦合，自主性高。
• 技术迭代方便。从单个服务开始尝试新技术。
• 扩展方便。可针对模块特点扩展，如CPU密集型加核数，内存需求大加内存。
• 故障隔离。分布式架构容错性好。

缺点

• 分布式系统的各种挑战。
• 架构师要求高。
  • 服务拆分定义难度大。避免出现紧耦合的分布式单体。
  • 开始使用微服务的时机把握。
  • 协调多个团队，有一定沟通成本。
• 维护成本高。
  • 运维和部署开销大。需要自动化运维、发布。
  • 重复造轮子。某些不够丰富的业务无法独立成服务，各自重复劳动。