一、微服务的定义

定义一

• 微服务是一种架构风格，将单体应⽤用划分成一组小的服务，服务之间相互协作，实现业务功能
• 每个服务运行在独⽴立的进程中，服务间采⽤轻量级的通信机制协作(通常是HTTP/ JSON)
• 每个服务围绕业务能力进行构建，并且能够通过自动化机制独立地部署 很少有集中式的服务管理，每个服务可以使用不同的语言开发，使⽤不同的存储技术

参考:https://www.martinfowler.com/articles/microservices.html

定义二

• Loosely coupled service oriented architecture with bounded context 
• 基于有界上下文的，松散耦合的面向服务的架构

二、什么是微服务架构

1. 由一组小的服务组成，例如将单体架构应用进行拆分成多块小的独立服务，服务有多小具体看业务进行划分。
2. 每个服务都是运行在独立的进程之中，以进程的方式去进行横向扩展。
3. 服务之间的通信方式是轻量级的，例如HTTP协议、RPC协议。
4. 一般要基于业务能力来构建微服务。
5. 每块服务都是能独立部署，团队之间不用太多协调，支持快速迭代。
6. 无集中式管理，每个团队管理的服务可以根据业务需要来选择相应技术栈。
7. 服务之间是松散耦合的，没有强依赖，微服务基于有界上下文，每个团队有独立的数据源，独立的去演化自己的服务。

问题：

1. 微服务独立部署以后给业务带来了什么好处？
2. 在分布式系统中，当每个团队都有独立的数据时会带来什么挑战？

三、微服务的利弊

利：

1. 强模块化边界。以服务作为组件来模块化，服务调用服务。
2. 可独立部署。独立开发，独立部署，有时候不需要其他团队的协同。
3. 技术多样性。每个团队可以选择自己的技术栈。

弊：

1. 分布式复杂性
2. 最终一致性
3. 运维复杂性
4. 测试复杂性

**如果你搞不不定⼀一个单块应⽤用，别指望微服务能够拯救你!

四、微服务架构的适用性

小规模应用的开发不推荐直接从微服务开始，构建成本高，所以单块优先。在交叉点可以考虑引入微服务。

五、微服务的组织架构

单体架构：从产品管理到用户体验需要协调，从用户体验到研发也需要协调，以此类推，如果从运维反馈问题到产品，这将是一个漫长的过程，产品反馈周期长，效率低。

微服务：一个团队围绕一个服务进行不断迭代，团队内部人员能够达到闭环，以平台进行交付，对外提高API，进行端到端的服务。

六、阿里巴巴的中台战略

七、服务分层概念

**BFF相关内容请参见 《微服务架构 BFF和网关是如何演化出来的》一文：

https://blog.csdn.net/weixin_45953989/article/details/119004779

八、微服务总体架构体系