01.对微服务的误解
a.反对者声称它的思想只是面向服务架构(SOA)的重塑.
b.把单体应用拆分为多个细粒度的单体应用就是微服务.
任何架构的发展都是站在前浪上面,因为微服务架构是在继承SOA架构的优点,解决SOA架构的问题上发展起来.
02.微服务架构是什么
微服务是一种架构风格.它的实现视图是单个组件(单个可以程序或WAR文件).
微服务是把一个大型复杂软件应用由一个或多个微服务组成.系统中的各个微服务可被独立部署,各个微服务之间是松耦合的.
每个微服务仅关注于完成一件任务并很好地完成该任务.在所有情况下,每个任务代表着一个小的业务能力.
内容阐述的是马丁富勒对微服务的定义,但是如果没有经历过SOA架构的问题,仅仅讨论微服务架构,是无法区分出来其特殊的亮点.根本原因在于微服务架构核心在于削减场景的复杂度.
03.微服务架构的特点
服务化单一职责:服务是单一的,通过服务API封装对外提供服务.区别单体架构,开发人员无法绕过服务的API直接访问服务内部的方法或者数据.
独立技术栈:微服务中的每项服务都可以有自己架构,有自己独特技术栈.
高度内聚自治:每个服务独立存在,单独部署,单独进程,相互隔离.
无(去)中心化:区别SOA的ESB,尽可能地实现"自服务".
易于重构扩展:单体微服务承载功能单一,大不了从新再来.
04.单体架构的问题
不敢动:随着时间推移,项目经过N个团队的开发,一个核心的业务的小需求变更,真心不太敢小手,害怕一修改就崩.
看不懂:随着时间推移而变得越来越臃肿,开发团队在每个冲刺阶段都要实现更多的用户需求,几年之后,小而简单的应用将会逐渐成长成一个庞大的单体.
没勇气:看着那么多代码,真想动手重构重构,但是看着臃肿的一堆代码,真没动人冲动.
代码冲突臃肿:项目过于臃肿,维护成本大,出现bug难定位.
并行开发,到处代码冲突.
资源无法隔离:共享一个数据库,或者一块内存.
如果一个功能模块突然访问量过大,可能影响整个系统的性能.
无法灵活扩展:单体系统也可以集群部署,但是不够灵活,我明明只是订单系统遇到了瓶颈,只需要将订单模块水平扩展就行,但现在要将整个系统水平扩展.不灵活.
交付周期长:所有功能得一起上线,一起构建,一起部署.
05.微服务解决的问题
第一,它解决了复杂问题.它把可能会变得庞大的单体应用程序分解成一套服务.虽然功能数量不变,但是应用程序已经被分解成可管理的块或者服务.
第二,这种架构使得每个服务都可以由一个团队独立专注开发.开发者可以自由选择任何符合服务API契约的技术.
第三,微服务架构模式可以实现每一个微服务独立部署.开发人员根本不需要去协调部署本地变更到服务.这些变更一经测试即可立即部署.
22-06-20