微服务架构的出现

单体应用之殇

• 无法快速迭代
  • 代码合并冲突，沟通成本大幅提高
  • 回归用例庞杂，无法快速迭代
• 无法快速恢复
  某版本小需求有bug需要回退整个版本的功能，且需要再走一遍冗长的发布流程

微服务架构优势

微服务架构是在 SOA（ Service-Oriented Architecture， 面向服务的架构）之上做的进一步扩展，通过领域建模等理论将一个大型应用拆分成了更细粒度且边界清晰的服务模块。
每个微服务都能被独立测试、独立部署，并借助 Docker 和 CI/CD（持续集成环境）完成快速上线。

• 快速迭代+快速回滚
  细粒度的可独立部署的小型服务，再加上敏捷开发模式的加持。

• 资源利用大大提高
  将硬件等资源定向分配给需要用到资源的微服务，实现差异化的资源利用。统计每个服务集群的线上压力水位，应用弹性计算技术在各个服务之间调配计算资源。

• 大幅降低协作成本
  码库、数据库、编译打包从“共享”变为了“独享”，微服务团队也保持了小规模特战队的模式。

• 高可用

  • 弹性机房水位调拨
    弹性机房实现了计算资源的自动分配，这种弹性伸缩能力必须建立在微服务化的基础上。它可以根据每个微服务的重要程度（核心服务 vs 边缘业务）以及当前承接的用户访问压力，动态地将计算资源（如虚机、云存储）分配给需要资源的服务。
  • 流量整形
    根据每个微服务承载能力的不同，控制外部流量抵达服务的速率。“限流”其实只是流量整形的一个场景，大型微服务的流量整形有很多种方式，比如匀速排队、流量预热、削峰填谷等等。
  • 熔断降级
    在流量高峰的时候，可以对边缘服务做人工降级，把计算资源腾挪给核心应用，降低核心服务的访问压力。除了人工降级以外，还可以为每个服务设置自动降级和熔断指标，比如当调用失败率达到某个阈值之后，开启自动降级措施，降低对下游业务的访问压力。