微服务发展史
从单体架构到分布式架构的演进
单体架构
通常来说，如果一个war包或者jar包里面包含一个应用的所有功能，则为单体架构
集群及垂直化
- 按照业务维度垂直拆分成多个子系统，每个子系统由单独维护部署（包括数据库等）
- 对Tomcat服务器进行集群部署，把多台Tomcat服务器通过网络进行连接组合，形成一个整体对外提供服务
SOA
SOA（Service-Orientend Architecture）面向服务架构。
把一些通用的、会被多个上层服务调用的共享业务提取成独立的基础服务，降低耦合，可以重用
微服务架构
针对可重用业务服务的更进一步优化，可以把SOA看成微服务的超集，多个微服务可以组成一个SOA服务
微服务和SOA区别
- SOA关注的服务的重用性（服务的复用）及解决信息孤岛问题
- 微服务关注解耦（降低耦合度）
- 微服务更关注DevOps持续交付（微服务划分粒度更细，与容器化技术结合更紧密）
微服务拆分的粒度没有统一标准，需要在粒度和团队之间寻找平衡。粒度越小，服务独立性更好，但是管理更复杂
微服务架构的挑战
优点
- 复杂度可控：一个服务只需要关注一个特定的业务领域，并通过定义良好的接口清晰表述服务边界
- 技术选型灵活：解耦后可以结合业务特性自由选择技术栈
- 可扩展性强
- 独立部署：某个微服务发生变更时不需要重新编译部署整个应用
- 容错性：故障隔离再单个服务中
挑战
边界上下文划分、数据库拆分、API交互、大量的微服务开发和维护、运维等
- 故障排查：交互链路比较长、日志多、定位问题根源可能比较困难
- 服务监控：需要对每一个微服务都实现监控，开销大
- 分布式架构的复杂性：远程通信可能会由于网络延迟故障导致程序的复杂度增加
- 服务依赖：各个服务之间会存在更多的依赖关系，需要考虑相关改变对不同服务的影响，使系统整体更为复杂
- 运维成本：多个微服务的正常运行、扩容、故障处理、快速部署和统一管理等
如何实现微服务架构
微服务架构图
微服务架构下的技术解决问题
微服务治理，将服务之间的依赖转化为服务对服务中心的依赖。
- 分布式配置中心
- 服务路由
- 负载均衡
- 熔断限流
- 链路监控