单体架构的弊端
- 随着业务扩张,开发、运维、部署变得复杂、缓慢,系统变得不稳定
- 数据管理容易产生安全漏洞
- 应用在开发时必须使用统一技术栈,很难切换到其他框架、技术
- 多开发人员同时修改代码库
-
微服务架构
根据分而治之思想,将定义服务边界、服务拆分、解耦,进行组件式开发、独立部署。
微服务设计理念参考Unix系统,继承设计模式中的单一职责原则,每个服务仅承担单一职责要点:
服务边界与服务拆分
- 服务协作
-
存在的缺点:
可用性降低
- 难以调试
- 处理分布式事务棘手
- 全能对象阻止业务拆分
- 学习难度加大,学习曲线
-
如何构建微服务架构应用
定义关键需求,识别服务时首先专注于业 务,通过业务逻辑视角可以有效快速的将核心微服务识别出来
- 识别应用包含的所有服务,核心微服务识别后需要围绕核心服务把相关联的服务都定义出来,并对服务进行分组、合并处理,最终完成服务定义
- 将第一步定义出来关键需求作为架构需求的场景来描述服务之间如何进行协作,根据每个业务进行服务协作分析,比如有的业务场景只需要某一个服务,而有的则需要多个服务进行或异步或同步协作,根据这些协作方法确定合适的交互方式(REST、RPC、消息…)
-
要点:
服务拆分 - 微服务粒度、拆分原则(单一职责SRP、共同封闭原则CCP)
- 服务治理 - 微服务自治(自治原则:分而治之-业务功能、数据管理)
- 服务交互 - (交互原则 - 如REST、JSON、状态码)