微服务简介

单体应用 VS 微服务

单体应用架构（monolithic architecture）

单体应用架构被认为是构建应用程序的传统架构方式。

单体应用程序是作为一个不可分割的单元构建的。

解决方案： 客户端用户界面、服务器端应用程序和数据库。

单体应用架构优势

1. 学习成本低，技术栈简单。
2. 易于部署

单体应用架构缺点

1. 随着应用需求的增加以及规模的扩大，其代码耦合度高，单体应用自身的代码复杂度会很高。
   eg: 修改任何一处细节，都会影响整个系统，必须全面协调开发、测试、部署。是的如阿健迭代慢、交付的效率低。
2. 扩展性差： 很难去针对某个模块进行扩展，只能针对整个应用程序扩展。★【IO密集型】和【CPU密集型】融合在一起，无法独立升级与扩容。
3. 新技术壁垒： 单体应用程序中应用新技术极其困难，必须重写整个应用程序。

微服务架构（microservice architecture)

单体架构是一个统一的整体，微服务体系解构则将其分解为较小的独立单元的集合。

微服务架构风格是将单个应用程序拆分为一组小服务的方法，每个服务都在自己的进程中运行并使用轻量级机制进行通信。

每个服务都可以独立更新、部署和扩展

微服务架构优势

• 独立组件： 所有服务都可以独立部署和更新，提供较大的灵活性

  • 针对IO密集型服务增加内存
  • 针对计算密集型服务增加CPU
    ---》 从而达到资源的合理分配

• 业务关注更加集中： 将应用程序分解为更小和更简单的组件, 将更加易于业务关注理解和管理。以个人业务目标为中心。
  微服务化让开发人员能够更加专注于自己的服务领域。（尽管整个生产线很庞大）

• 更好的可扩展性： 微服务的另一个优点是每个服务都可以独立缩放，结合容器化编排管理（k8s、docker等）。可快速实现服务的扩容与缩放。

• 选择技术的灵活性： 工程团队不受一开始就选择的技术限制，可自由地为每个微服务应用各种技术和框架。只要保证接口通信协议一致即可。

微服务架构缺点

• 编码复杂度增加： 微服务架构是分布式系统，因此会产生分布式的数据库操作以及分布式事务等复杂度更高的编码需求。
  一定要进行合理的微服务拆分，合理的确定服务边界，保证服务内部高内聚，降低分布式事务等操作出现的概率。

• 额外关注： 微服务由于其多主机、分布式部署，所以它们需要很多的额外关注：如统一配置，统一日志记录，统一的指标监控，统一的运行状况检查等。

• 测试： 虽然单个微服务的测试复杂度降低，但是众多可独立部署的服务使集成测试变的更加困难。
  

微服务拆分原则

• 以业务模型切入，eg: 订单管理、商品管理等。

• 单一职责、高内聚：单个微服务的职责尽量单一。但粒度要适中，不能过度拆分！！！

• 充分考虑团队结果：微服务的拆分要充分考虑团队的结果，与微服务开发运维之间的关系。

• 演进式拆分： 如果各个方面资源不允许，可以考虑演进式拆分

• 避免环形依赖与双向依赖：避免微服务之间的环形依赖或双向依赖。