单体应用到微服务架构
微服务“三大功能，两大特性”
- 三大功能是指微服务核心组件的功能维度，由浅入深层次递进；而两大特性是构建在每个服务组件之上的高可用性和高可扩展性。
- 服务间通信，包括服务治理、负载均衡、服务间调用；
- 服务容错和异常排查，包括流量整形、降级熔断、调用链追踪；
- 分布式能力建设，包括微服务网关、分布式事务、消息驱动、分布式配置中心。
单体应用之殇
- 以 Java 单体应用为例，我们将业务逻辑打包在一起，做成一个 WAR 包部署到 Tomcat、JBoss 之类的容器中，对外提供服务。
- 业务上了一定规模之后，再通过集群化水平扩展的方式，将单体应用部署到一个集群中，承接更大的用户访问量。
- 然而，随着业务复杂度的进一步提升，单体应用在生产力和高可用性层面就面临了巨大的挑战。
微服务架构的优势
- 微服务架构是在 SOA（面向服务架构）之上做的进一步扩展。
- 在一线实践中，我们通过领域建模等理论将一个大型应用拆分成了更细粒度且边界清晰的服务模块。
- 而且，每个微服务都能被独立测试、独立部署，并借助 Docker 和 CI/CD（持续集成环境）完成快速上线，不必像单体应用一样经历繁琐的 release 流程和漫长的发布窗口。
- 每个微服务就像一个“麻雀虽小、五脏俱全”的小王国，它拥有独立的代码库和数据库 Schema，通常由一个小规模的微服务技术团队全权负责，这个团队汇聚了产品、技术、架构等人员，采用 Scrum 之类的敏捷开发流程做快速迭代。基于此，微服务具备了“独立演进”能力。
- 微服务架构有这样几个天然的优势：
- 快速迭代 + 快速回滚。
- 细粒度的可独立部署的小型服务，再加上敏捷开发模式的加持，可以对产品功能实现快速迭代。
- 如果迭代过程中发现线上 Bug，也可以在最短的时间内做线上回滚，并且不会影响到其他应用的正常发布。
- 资源利用大大提高
- 可以将硬件等资源定向分配给需要用到资源的微服务，实现差异化的资源利用。
- 统计每个服务集群的线上压力水位，应用弹性计算技术在各个服务之间调配计算资源。
- 大幅降低协作成本
- 代码库、数据库、编译打包从“共享”变为了“独享”，微服务团队也保持了小规模特战队的模式，进一步降低了组内组外的沟通协作成本。
- 高可用
- 高可用是系统设计的第一目标。
- 弹性机房水位调拨
- 弹性机房实现了计算资源的自动分配，这种弹性伸缩能力必须建立在微服务化的基础上。
- 它可以根据每个微服务的重要程度（核心服务 vs 边缘业务）以及当前承接的用户访问压力，动态地将计算资源（如虚机、云存储）分配给需要资源的服务。
- 流量整形
- 根据每个微服务承载能力的不同，控制外部流量抵达服务的速率。
- “限流”其实只是流量整形的一个场景，大型微服务的流量整形有很多种方式，比如匀速排队、流量预热、削峰填谷等等。
- 熔断降级
- 在流量高峰的时候，我们可以对边缘服务做人工降级，把计算资源腾挪给核心应用，降低核心服务的访问压力。
- 除了人工降级以外，我们还可以为每个服务设置自动降级和熔断指标，比如当调用失败率达到某个阈值之后，开启自动降级措施，降低对下游业务的访问压力。
