为什么大公司一定要使用微服务？微服务杂谈，重难点整理

• 技术选型的多样性

缺点：

• 分布式带来编程复杂度，远程调用的消耗

• 舍弃强一致性，实现最终一致性

• 操作复杂性要求有一个成熟的运维团队或者运维基础设施

为什么要采用微服务

是否选择微服务取决于你要设计的系统的复杂度。微服务是用来把控复杂系统的，但是随之而来的就是引入了微服务本身的复杂度。需要解决包括自动化部署、监控、容错处理、最终一致性等其他分布式系统面临的问题。即使已经有一些普遍使用的解决方案，但是仍然是有不小的成本的。

生产力和复杂度的关系如图所示，可见系统越复杂，微服务带来的收益越大。此外，无论是单体应用还是微服务，团队的技能都需要能够把控住。

马丁.福勒的一个观点是：除非管理单体应用的成本已经太复杂了（太大导致很难修改和部署），否则都不要考虑微服务。大部分应用都应该选择单体架构，做好单体应用的模块化而不是拆分成服务。

因此，系统一开始采用单体架构，做好模块化，之后随着系统变得越来越复杂、模块/服务间的边界越来越清晰，再重构为微服务架构是一个合理的架构演化路径。

四个可以考虑上微服务的情况：

1. 多人开发一个模块/项目，提交代码频繁出现大量冲突。

2. 模块间严重耦合，互相依赖，每次变动需要牵扯多个团队，单次上线需求太多，风险大。

3. 主要业务和次要业务耦合，横向扩展流程复杂。

4. 熔断降级全靠if-else。

微服务的三个阶段：

1. 微服务1.0：

仅使用注册发现，基于SpringCloud或者Dubbo进行开发。

2. 微服务2.0：

使用了熔断、限流、降级等服务治理策略，并配备完整服务工具和平台。

3. 微服务3.0：

Service Mesh将服务治理作为通用组件，下沉到平台层实现，应用层仅仅关注业务逻辑，平台层可以根据业务监控自动调度和参数调整，实现AIOps和智能调度。

微服务架构

先决条件

• 快速的环境提供能力：

依赖于云计算、容器技术，快速交付环境。

• 基本的监控能力：

包括基础的技术监控和业务监控。

• 快速的应用部署能力：

需要部署管道提供快速的部署能力。

• Devops文化：

需要具有良好的持续交付能力，包括全链路追踪、快速环境提供和部署等，还需要快速的反应能力（对问题、故障的快速响应），开发和运维的协同工作。

此外，根据康威定律和逆康威定律（技术架构倒逼组织架构改进），组织架构也是一个很关键的因素。对应于微服务架构，组织架构需要遵循以下原则：

1. 一个微服务由一个团队维护，团队成员以三人为宜。

2. 单个团队的任务和发展是独立的，不受其他因素影响。

3. 团队是功能齐全、全栈、