-
面向失败设计
-
渐进式设计
综合来看,其优缺点如下:
优点:
-
模块的强边界
-
独立部署
-
技术选型的多样性
缺点:
-
分布式带来编程复杂度,远程调用的消耗
-
舍弃强一致性,实现最终一致性
-
操作复杂性要求有一个成熟的运维团队或者运维基础设施
为什么要采用微服务
是否选择微服务取决于你要设计的系统的复杂度。微服务是用来把控复杂系统的,但是随之而来的就是引入了微服务本身的复杂度。需要解决包括自动化部署、监控、容错处理、最终一致性等其他分布式系统面临的问题。即使已经有一些普遍使用的解决方案,但是仍然是有不小的成本的。
生产力和复杂度的关系如图所示,可见系统越复杂,微服务带来的收益越大。此外,无论是单体应用还是微服务,团队的技能都需要能够把控住。
马丁.福勒的一个观点是:除非管理单体应用的成本已经太复杂了(太大导致很难修改和部署),否则都不要考虑微服务。大部分应用都应该选择单体架构,做好单体应用的模块化而不是拆分成服务。
因此,系统一开始采用单体架构,做好模块化,之后随着系统变得越来越复杂、模块/服务间的边界越来越清晰,再重构为微服务架构是一个合理的架构演化路径。
四个可以考虑上微服务的情况:
-
多人开发一个模块/项目,提交代码频繁出现大量冲突。
-
模块间严重耦合,互相依赖,每次变动需要牵扯多个团队,单次上线需求太多,风险大。
-
主要业务和次要业务耦合,横向扩展流程复杂。
-
熔断降级全靠if-else。
微服务的三个阶段:
- 微服务1.0:
仅使用注册发现,基于SpringCloud或者Dubbo进行开发。
- 微服务2.0:
使用了熔断、限流、降级等服务治理策略,并配备完整服务工具和平台。
- 微服务3.0:
Service Mesh将服务治理作为通用组件,下沉到平台层实现,应用层仅仅关注业务逻辑,平台层可以根据业务监控自动调度和参数调整,实现AIOps和智能调度。
微服务架构
先决条件
- 快速的环境提供能力:
依赖于云计算、容器技术,快速交付环境。<