传统高可用架构缺点

image.png
在反向代理集群下，是众多 web服务器构成的高可用集群。
将一个巨型单体应用复制成 N 个单体应用，组成分布式集群。

数据模型变更困难

在同一个 war 包内，数据访问层没有划分领域模型，对于不同的服务模块都是直接访问数据库获取数据。
一个表会被系统中的众多服务引用，导致表结构难以更改。

通过微服务架构，可以将表结构改变的影响范围限制在当前的微服务中，上下游服务只要对接微服务的接口即可。

底层组件变更困难

更改数据库访问规则，更换数据库，增加热点数据缓存读写，分库分表，牵一发而动全身

代码复用带来维护成本

整个应用的代码掺杂在一起，互相引用
路见不平重构一番，终成屎山

当业务需要添加新功能，发现很久之前自己写的一个方法改一下就能用，可隔壁的同事没打招呼也用了这个方法，被你一改，别人的服务搞挂了。。

互联网迭代快，这种事情每天都在上演。

微服务模块由于职责边界足够清晰，规模可控便于快速变更和测试，可以快速测试上线，即使线上问题回滚也只限于微服务范围内，不影响上下游其他应用发布。

微服务优点

  • 快速响应变更：单一职责，独立部署
  • 独立扩展：边界清晰，不过度受制于技术栈
  • 精粒度业务控制：降级熔断，局部限流
  • 面向业务/领域模型：不直接依赖数据模型，易于抽象，快速落地新应用

微服务缺点

  • 部署结构复杂：模块众多，一堆额外组件
  • 依赖平台支撑：依赖微服务组件，增加研发成本，技术要求高
  • 分布式问题：保证数据一致性问题，需要异常补偿
  • 要求拆分水平：拆分 过细/过粗 都会使复杂度更高

微服务要点

  • 服务治理与负载均衡
    • 服务治理：服务间调用，集群虚拟机的上下线，集群扩容，探知集群中各个服务节点的状态变化
    • 将海量的用户请求，根据服务器的性能、带宽、响应快慢 动态的分配到不同机器上，这就是负载均衡要解决的事情
  • 服务容错
    • 在高并发场景下，有的服务会承担较大的访问量，可能会导致响应慢或超时。调用方在超时后会经常发起重试，这样会进一步增加下游应用的访问压力，造成恶性循环。
    • 微服务通过 降级 与 熔断技术 解决这类问题，称为服务容错。
  • 配置管理
    • 微服务需要动态配置，不同服务配置不同，服务配置管理专门解决这类问题
  • 服务网关
    • 网关负责将用户请求转发到不同服务器，微服务的网关需要更加智能，会感知服务上下线的变化
  • 调用链路追踪
    • 记录事件完整过程，精准甩锅
  • 消息驱动
    • 消息驱动 加 削峰填谷 巨抗压
    • 微服务各个系统间的解耦也可以用消息组件来实现。
  • 限流
    • 再厉害的系统也有瓶颈，限流是最经济高效，在源头处消减系统压力的手段。
    • 微服务节点数量多，单机版限流不能解决问题，需要引入分布式限流