微服务思考

随着系统的架构和功能越来越复杂，单体应用已经满足不了性能和可维护性的需求，需要将功能拆分，因此产生微服务。通过将不同功能的模块拆分，可以保证高可扩展，高性能，高可用，易测试的特性。由于将服务拆分，会带来一些问题：

• 节点不可靠，节点之间的通讯不可靠。不像单体应用调用不是成功就是失败，服务间调用会有延迟，超时，丢包，乱序等现象。
• 分布式事务：由于不同服务使用各自的数据库，acid特性已无法保证，由强一致性到最终一致性

即使系统99.999%的时间是正常提供服务的，大量的节点长时间工作也会出问题。因此做架构设计时需考虑异常出现会怎么办。

微服务需要满足一下几个特性：

• 计算节点无状态
• 接口幂等

微服务相关组件：

• 注册中心：eureka，zookeeper，nacos
• 配置中心：config，apollo
• Rpc框架：feign，dubbo
• 负载均衡：ribbon
• 限流熔断器：hystrix，sentinel
• 网关：gateway

可以认为注册中心是一个中心化存储，通过http的形式暴露哪些服务可以被调用。服务也可以通过http注册到配置中心。配置中心保存了各个服务的配置信息。服务从注册中心获取可访问的服务列表，根据一定的负载均衡策略，通过rpc调用下游服务。下游接口由限流熔断器保证安全，防止被击垮。

其他：

• 监控告警：actuator，prometheus，alertmanager，grafana
• 任务调度
• 跑批
• 鉴权

保证接口高可用：

• 熔断
• 降级
• 限流
• 幂等

对于分布式存储，典型的如Redis cluster，Zookeeper，Es，Kafka，eureka，需要考虑：

• 做到高可用，解决数据冗余带来的一致性问题，由CAP到BASE，数据一致性协议
• 有没有管理节点/主节点
• 主/从节点挂了如何处理
• 数据如何分片
• 是否读写分离