马丁.福勒的一个观点是:除非管理单体应用的成本已经太复杂了(太大导致很难修改和部署),否则都不要考虑微服务。大部分应用都应该选择单体架构,做好单体应用的模块化而不是拆分成服务。
因此,系统一开始采用单体架构,做好模块化,之后随着系统变得越来越复杂、模块/服务间的边界越来越清晰,再重构为微服务架构是一个合理的架构演化路径。
四个可以考虑上微服务的情况:
-
多人开发一个模块/项目,提交代码频繁出现大量冲突。
-
模块间严重耦合,互相依赖,每次变动需要牵扯多个团队,单次上线需求太多,风险大。
-
主要业务和次要业务耦合,横向扩展流程复杂。
-
熔断降级全靠if-else。
微服务的三个阶段:
-
微服务1.0:
仅使用注册发现,基于SpringCloud或者Dubbo进行开发。
-
微服务2.0:
使用了熔断、限流、降级等服务治理策略,并配备完整服务工具和平台。
-
微服务3.0:
Service Mesh将服务治理作为通用组件,下沉到平台层实现,应用层仅仅关注业务逻辑,平台层可以根据业务监控自动调度和参数调整,实现AIOps和智能调度。
微服务架构
先决条件
-
快速的环境提供能力:
依赖于云计算、容器技术,快速交付环境。
-
基本的监控能力:
包括基础的技术监控和业务监控。
-
快速的应用部署能力:
需要部署管道提供快速的部署能力。
-
Devops文化:
需要具有良好的持续交付能力,包括全链路追踪、快速环境提供和部署等,还需要快速的反应能力(对问题、故障的快速响应),开发和运维的协同工作。
此外,根据康威定律和逆康威定律(技术架构倒逼组织架构改进),组织架构也是一个很关键的因素。对应于微服务架构,组织架构需要遵循以下原则:
-
一个微服务由一个团队维护,团队成员以三人为宜。
-
单个团队的任务和发展是独立的,不受其他因素影响。
-
团队是功能齐全、全栈、自治的,扁平、自我管理。
基础设施
微服务的推行需要依赖于很多底层基础设施,包括提供微服务的编译、集成、打包、部署、配置等工作,采用PaaS平台解决微服务从开发到运行的全生命周期管理,同时提供异构环境管理、容器资源隔离与互通、服务伸缩漂移、服务升级与回退、服务熔断与降级、服务注册与发现。