微服务-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	风险	大系统被拆分为小系统，风险可被控制在小系统内，但也引入了各小系统之间的交互风险	系统是一个整体，一荣俱荣，一损俱损

参考

Re：重识微服务架构

一篇文章快速理解微服务架构