微服务-01初识
微服务初识
微服务架构
传统的SOA架构已经是面向服务的应用架构了,整个架构中其实已经包含了各式各样不同的服务,服务之间通过相互依赖最终对外提供一系列功能;ESB企业级消息总线通常被引入进传统SOA架构,从而实现规整、可治理的星型结构。
与此同时微服务架构其实是也是SOA思想,但是更进一步的是它更强调的是子系统的组件化和单一功能化。站在部署角度来看,相比传统SOA架构中的单体应用,微服务架构下的应用不仅在功能架构上做了模块化拆分,而且在最终的部署架构上也有独立的部署单元与之相对应。由此带来了微服务架构的以下特点:
-
每个微服务都是单一职责原则的体现。无论是从服务的拆分、模块的开发、服务的部署角度来说,微服务拥有自己独特的角色,独立的开发团队,自己独立的进程,可以被独立的部署运行。
-
每个微服务在围绕具体业务构建时,通常采用轻量级的通讯方式而非传统的webservice接口;
-
每个微服务可以完全独立于其他服务进行快速的水平扩展
总的来说微服务架构就像更细致的模块化的生产模式,每个服务都是一个特定功能的标准化零件,最终整个系统是由这些个标准化的零件组合而成。但是如果从技术的演进来说,微服务架构更像是模块化开发+分布式计算的综合应用。
微服务架构的优点和问题
正如微服务架构的特点一样,微服务拆分之后有着自己的优点,但不能忘记微服务最终是要合在一期工作的,这时也就引入了不少问题:
- 分布式计算固有的复杂性,比如分布式环境中的复杂的网络和消息传递问题。
- 分布式环境下需要采用分布式事务机制来解决数据一致性问题;
- 测试、运维复杂性,一方面数量巨大、碎片化的微服务系统的持续部署会给运维带来巨大的压力;另一方面复杂的调用链路会给监控、排错带来巨大的困扰。
单体架构、微服务架构对比
S/N | 对比点 | 微服务架构 | 单体架构 | 结论 |
---|---|---|---|---|
1 | 上手难度 | API 接口调用 | 数据库共享或本地程序调用 | 单体架构胜 |
2.1 | 开发效率(简单项目) | 早期设计和沟通的工作量加大,随着项目规模和时间的推移,效率变化不大 | 早期工作量小,随着项目规模和时间的推移,效率大幅度下降 | 单体架构胜 |
2.2 | 开发效率(复杂项目) | 早期设计和沟通的工作量加大,随着项目规模和时间的推移,效率变化不大 | 早期工作量小,随着项目规模和时间的推移,效率大幅度下降 | 微服务架构胜 |
3 | 系统设计(高内聚低耦合) | 每个业务单独包装成一个微服务,数据和代码都从物理上隔离开来,实现高内聚低耦合相对容易 | 以包的形式对代码进行模块划分,控制得当即可实现高内聚。但最终都是在数据层面将整个系统耦合在一起 | 微服务架构胜 |
4 | 系统设计(扩展性) | 独立开发新模块,通过 API 与现有模块交互 | 在现有系统上修改,与现存业务逻辑高度耦合 | 微服务架构胜 |
5 | 需求变更响应速度 | 各个微服务组件独立变更,容易实施敏捷开发方法 | 需要了解整个系统才可以正确修改,容易导致不相关模块的意外失败 | 微服务架构胜 |
6 | 系统升级效率 | 各个微服务组件独立升级,上手和开发效率高,影响面小 | 需要了解整个系统才可以正确修改,容易导致不相关模块的意外失败 | 微服务架构胜 |
7 | 运维效率 | 大系统被拆分为多个小系统,部署和运维难度加大,但可以利用 DevOps 等方式将运维工作自动化 | 简单直接 | 单体架构胜 |
8 | 知识积累 | 微服务组件可以在新项目中直接复用,包括前端页面 | 一般以共享库的形式复用后台代码 | 微服务架构胜 |
9.1 | 硬件需求(简单项目) | 一个系统需部署多个微服务,需要启动多个运行容器 | 整个系统只需要一个运行容器 | 单体架构胜 |
9.2 | 硬件需求(高要求项目) | 按需为不同业务模块伸缩资源节点 | 为整个系统分配资源,导致冗余 | 微服务架构胜 |
10.1 | 项目成本(简单系统) | 项目早期和后期,成本变化曲线平缓 | 项目早期成本低,后期成本大 | 单体架构胜 |
10.2 | 项目成本(复杂系统) | 项目早期和后期,成本变化曲线平缓 | 项目早期成本低,后期成本大 | 微服务架构胜 |
11 | 非功能需求 | 为单独的微服务按需调优,甚至更换实现方式和程序语言 | 为整个系统调优,牵一发而动全身 | 微服务架构胜 |
12 | 职责、成就感 | 拥有明确的职责划分,主人翁意识和成就感加强,容易形成自组织型团队 | 职责不明确,容易产生扯皮行为 | 微服务架构胜 |
13 | 风险 | 大系统被拆分为小系统,风险可被控制在小系统内,但也引入了各小系统之间的交互风险 | 系统是一个整体,一荣俱荣,一损俱损 |