随着系统的架构和功能越来越复杂，单体应用已经满足不了性能和可维护性的需求，需要将功能拆分，因此产生微服务。通过将不同功能的模块拆分，可以保证高可扩展，高性能，高可用，易测试的特性。由于将服务拆分，会带来一些问题：
- 节点不可靠，节点之间的通讯不可靠。不像单体应用调用不是成功就是失败，服务间调用会有延迟，超时，丢包，乱序等现象。
- 分布式事务：由于不同服务使用各自的数据库，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，数据一致性协议
- 有没有管理节点/主节点
- 主/从节点挂了如何处理
- 数据如何分片
- 是否读写分离
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。