漫谈什么时候从单体架构迁移到微服务？

原文: 漫谈什么时候从单体架构迁移到微服务？

面对微服务如火如荼的发展，不少人都在了解，学习但愿能在本身的项目中帮得上忙，当你对微服务的庐山真面目有所了解后，接下来就是说服本身了，到底如何评估微服务，何时使用微服务，什么时间点最合适，须要哪些技术储备和资源投入等等，这些都是你须要面对和解决的。

本文从单体架构，微服务架构，微服务风险评估，微服务落地条件等几个方面探讨微服务的落地过程，但愿对你有所启发。

　　讲解微服务以前，咱们先简单了解下单体架构。

1、单体架构

　　

单体架构的优势：

• 快速开发和验证想法，证实产品思路是否可行

• 投入资源和成本，包括人力和物力相对比较节约

单体架构的缺点：

　　随着业务的复杂度增长，单体的灵活度会逐渐降低，好比：

• IDE过载：随着代码量增长，代码总体编译效率降低。

• 规模化：没法知足团队规模化高效开发。

• 系统开发、测试、部署的冲突和效率低下等问题

• 只能关注一套技术栈

• 应用扩展性比较差

• 海量用户高并发访问数量有限

单体适用场景：

　　架构设计的三大原则告诉咱们，架构须要的是简单、适度、演化。

　　对于项目起步阶段，单体是最高效也是最节省成本的方式。由于初期阶段，因为人力，成本，业务熟悉程度，微服务技术积累等因素，如何过分设计可能工期和复杂度会急剧上升，形成交付困难，问题百出，从而错过了时间窗口。最合适，简单的方式仍是单体优先，这是创业公司的特色决定的。固然设计面向微服务的单体架构也是一种聪明的方法，这遵照了系统演化的法则。

单体分层目的：

　　不管采起何种维度的架构分层，分层的最核心目的是保证各层之间的差别足够清晰，边界足够明显，为未来可能产生的变化提供最容易、最小化的修改。好比客户端要从安卓替换为IOS，底层无须任何改动，就像替换积木同样。又好比，设备须要接入新的设备或协议，其余层也不须要作任何变化，能够无缝平滑接入任何设备。

建议

　　若是前期在业务不十分清晰，求的是验证想法，证实产品思路是否可行性，而且业务量不大，仅限于省级范围，建议只要对当前架构稍加改良升级就能够了，这样改动量相对较小，且至少能支撑必定时间段的业务增加。

2、微服务架构

微服务的优点

　　支撑的业务更加庞大，能够支撑海量用户高并发和海量设备接入，支持分布式多机房，多区域部署，支持服务器无限扩容。支持私有云，公有云，混合云等部署方式。因此微服务是大多数互联网公司的首选。

微服务的代价

• 技术门槛高：微服务包括，服务描述，注册中心，服务框架，服务监控，服务追踪，服务治理等几大基本组件，以上每一个组件缺一不可，每一个组件展开又包括不少技术门槛，好比，容器技术，持续部署，DevOps等相关概念。
• 复杂性增长：相对单体架构将全部功能打包部署在一块儿，集中地进行开发、测试和运维，微服务会将这些单体的服务进行拆分部署，业务拆分粒度是一个难点，拆分后服务聚合也是一个麻烦。由于服务粒度增长后，相互调用，相互依存，因此问题排查难度会增长，就须要一套完整的服务监控，服务跟踪和治理的系统。
• 观念变化：微服务不只仅是技术的升级，更是开发方式、组织架构、开发观念的转变。
• 前期投入成本较高

微服务架构图

　　微服务架构图谱谷歌或Bing下，能够看到各类各样的架构图，源于业务和架构师自身的喜爱或者粗细粒度，可是每一个架构图的基本组件和架构分层都差异不大，只是有的细一些，有的粗一下。好比有客户端层，容器层(K8S)，API Gateway，微服务集群层，EventBus层是必需要有的，至于服务监控和服务跟踪、服务治理自己就是一个完整的系统，粒度就没有细了。基于这些概念，我把架构图稍微细化一下，这里省去服务监控跟踪和治理的部分，后续单独抽离出来分析。

　　这边的架构图谱相对以前的架构图，更加贴近业务，粒度也更细，虽然个别组件有所省略，好比跟踪和治理部分。

　　

　　以上架构图主要分4层，每一个层次遵循架构分层的核心思想：关注点分离，职责各异，边界清晰。

　　第1层：客户端：理论上包含一切能够联网的设备，包括移动设备，Android、IoS、Pad、微信、微博、QQ、Web、各自浏览器、物联网设备等等……

　　第2层：API网关：包括服务注册，发现，认证受权，单点登陆，熔断，限流……网关的知识点丰富，是微服务的核心之一。

• • 假如网关对外提供统一的地址：www.jackyfei.com

　　第3层：微服务集群：包括各类具体的microservice，好比纵向划分的业务服务(用户服务，订单服务，……)，横向划分的基础或公共服务(元数据服务，公共服务……)

　　其余微服务的地址多是这样的：

• • 用户服务：1.user.jackyfei.com
  • 订单服务：2.order.jackyfei.com
  • 元数据服务：3.base.jackyfei.com
  • 消息服务：4.msg.jackyfei.com

　　第4层：事件总线：Event Bus 目的是消息解耦，不要让服务之间直接的连接。不一样与SOA的服务总线，事件总线相对比较轻量，常常基于消息队列引擎进行解耦，目的是为了让服务之间的关联弱化，不直接进行关联。不少时候用的是相对稳定、可靠、企业级的RabbitMQ。

　　微服务的架构其实不难，根据以上的架构，每种业务均可以进行套用，这里的难点在于服务的划分和粒度控制，另外如何管理膨胀的服务是一个麻烦事。

3、什么时候采用微服务?

3.1杨波说

　　这里引用架构师杨波(前Ebay架构师，目前任职拍拍贷研发部总监，资深技术架构师，微服务技术专家)的一些观点：

　　“企业一开始不推荐直接使用微服务，由于微服务须要前期基础设施的投资，复杂性很高，若是对问题领域并非很理解，一开始用微服务，你很难去划分服务的边界，你的生产力反而会比较低，并且你花了很大精力进行开发，你的产品并无被市场验证过，有可能会失败，因此这个选项风险会比较高。因此咱们推荐的是单块优先，先从单块运用作起，这样成本低，团队成员也比较少，无须太多研发投入，就能够交付一些基本的功能给客户使用。

　　随着应用愈来愈成功，客户增长，你的系统复杂度会愈来愈高，就会出现单块应用和团队规模之间的矛盾，生产力会随着业务复杂度逐渐下降。因此在一些初创型公司，你更多看到的是单块应用，只有一些中大型的公司会看到微服务架构。”

      

　　“交叉点代表，业务已经到达了必定的复杂性，单块应用已经没法知足业务增加的须要，研发效率开始降低了，而微服务能够提高研发和交付的效率。这个点须要架构师去综合，权衡。我的经验，通常团队须要达到百人规模，才去考虑微服务。”

　　以上的观点讲的很中肯，给个人启发和帮助很是大。这里的交叉点怎么来肯定和评估是重点，好比咱们上线一个社交姑且叫抖信，初期为了快速上线，验证可行性，能够只开发首页聊天、通信录、评论等基本功能。产品上线后，通过一段时间的运营，用户开始逐步增多，可行性验证经过，下一阶段就须要进一步增长更多的新特性来吸引更多的目标用户，好比再给这个社交抖信添加朋友圈、消息通知、游戏、电商等等功能。

　　“通常状况下，这个时候就须要大规模地扩张开发人员，以支撑多个功能的开发。若是这个时候继续采用单体应用架构，多个功能模块混杂在一块儿开发、测试和部署的话，就会致使不一样功能之间相互影响，一次打包部署须要全部的功能都测试 OK 才能上线。

　　不只如此，多个功能模块混部在一块儿，对线上服务的稳定性也是个巨大的挑战。好比 A 开发的一个功能因为代码编写考虑不够全面，上线后产生了内存泄漏，运行一段时间后进程异常退出，那么部署在这个服务池中的全部功能都不可访问。

　　根据个人实际项目经验，一旦单体应用同时进行开发的人员超过 10 人，就会遇到上面的问题，这个时候就该考虑进行服务化拆分了。” ---胡忠想(微博微服务技术专家)

　　至此，咱们什么时候采用微服务已经十分明确了，关键是 业务复杂度和 团队规模两大要点，而业务复杂度和市场窗口是权衡和抉择的首要因素。

3.2微服务落地条件评估

　　通常状况下，业务系统引入新技术就必然会带来架构的复杂度提高，在具体决策前，你先要认识到新架构会带来哪些新的问题，这些问题你和你的团队是否可以解决？如何解决？是本身投入人力建设，仍是采用业界开源方案？假如你和我同样都是微服务的旁观者或者学习者，那么下面的评估也许对你又所参考。

3.2.1落地方式选择

不一样的落地方式决定不一样的资源配置。

方式一：借力外部架构咨询公司提供架构DEMO和培训服务助推内部团队技术转型升级。

方式二：招聘相关经验丰富的人员进来，自行研究和搭建架构并作内部培训，推进团队技术升级。

建议：若是比较紧急，采用第一种方式，由于招聘匹配的人才比较困难，等不起。可是无论是那种方式，对于团队来讲都须要必定的技术人才储备方便后续交接和运维。

3.2.2人才储备

　　这里分红两类人员，一类是研究型，一类是应用型。研究型主要是以技术攻坚为主，负责微服务的核心组件的研究和开发，好比服务发布和订阅，服务跟踪和监控，服务的治理；应用型主要是负责技术理解应用为主。

　　

3.2.3技术储备

　　微服务相关技术栈和微服务周边技术栈。周边技术栈包括领域驱动涉及，持续交付，分布式至少，负载均衡，CAP理论，缓存原理，DevOps和容器化技术。

3.2.4团队规模评估

　　杨波在给微服务的开发团队规划时候给了一个百人左右的大概预估，至于到底须要多少开发人员就没有细说，可能做者自己呆过的公司都是大厂，对人力成本控制没有那么大的包袱，对于中小企业，人力是最贵的成本。若是要必定要上微服务，该怎么办？

　　对于微服务的团队规模众说纷纭，有的说要百来号人；有的说须要精兵10人左右；有的说和人数没有关系，只和业务有关；有的说一个懂微服务的架构师也能搞定。这些说法都比较笼统，若是你想上微服务，人力评估包括人力、能力、人数等等，这些因素仍是很是重要的，毕竟成本才是商业的本质，有可能不客观的规划会致使项目的溃败。 

　　对于微服务的团队规模是哪些方面决定的呢？我以为至少要从如下两个维度来评估：

　　 业务规模：若是大家的业务架构很是复杂，有仓储系统开发，ERP系统，OA系统，订单系统等等，业务越多，需求人数越多(这里人数指的都是后台开发人数)。

　　 技术能力：另外，别忘了非功能性的开发，好比API网关，服务跟踪、治理等也是须要人去开发和维护的，这些非功能性的核心组件须要多少人，因为没有完整的开发经验，加上个别组件，好比跟踪系统，开发的程度可深可浅，开发周期可长可短，以目前我的的经验还没法给与合理的建议。可能牛人1我的两周就够了，也可能高级开发2我的，一人分工三个核心组件，两周也够用。或者架构外包，只要交接的人能跟上，也是一种解决方案。

　　总结：1个精通微服务落地经验的架构师是必不可少的，围绕架构师周边一帮高级开发，按 根据实际业务来肯定，通常一个开发负责2-3个核心模块，不宜太多，好比目前核心模块有8个，对应人数配置大概在3-4个左右。

3.3转微服务风险评估

3.3.1重写面广

　　因为是架构级别的调整，以前能保留下来的大部分是解耦比较好的代码，好比前端代码，采集服务代码，部分业务逻辑代码，因此对现有框架冲击面比较大。

3.3.2复杂度高

　　由于微服务是一种观念和思想，又是新近技术，自己就有各类架构实现方式和技术解决方案。因此对技术人员来讲，对比选型自己就是一个考验。加上自己涉及的技术面就比较广，因此复杂度和门槛相对比较高。

可是该技术发源于亚马逊，通过近些年的发展，虽然还在发展，可是已经相对成熟。

3.3.3人员配置

　　微服务架构工做量主要集中在后端，对后端开发人员的技术级别有较高的要求，主要是对微服务原理和开源组件的熟悉上，同时须要具有总体的微服务的意识。暂时不具有总体微服务开发意识和经验，须要经过培训后进行转型升级。

3.3.4合做方式

　　若是采用借助外部架构力量来助推架构升级，和架构单位的合做就不是简单的外包，涉及的面会变得比较广，在彻底交接过来以前，周期会比较长。包括对咱们业务架构的深刻了解，而后根据业务架构绘制可靠技术架构蓝图，再根据技术蓝图进行落地实施(不建议只提供架构方案而由其余单位实施落地)，包括新系统的开发，旧系统的升级，固然这种升级是平滑过分的，对业务窗口并不会产生影响。

3.4合理的拆分姿式

　　如何正确拆分？这里正确指的是合理，由于没有绝对的标准。按照前人的经验能够分为纵向和横向两种划分方法：

3.4.1纵向拆分

　　是从业务维度进行拆分。标准是按照业务的关联程度来决定，关联比较密切的业务适合拆分为一个微服务，而功能相对比较独立的业务适合单独拆分为一个微服务，好比上图中的订单服务，用户服务。另外粒度过小，服务聚合是一个坑，粒度太大，分和没分一个样。

3.4.2横向拆分

　　是从公共且独立功能维度拆分。标准是按照是否有公共的被多个其余服务调用，且依赖的资源独立不与其余业务耦合。好比上图中的元数据服务和消息服务。

3.4.3总结

　　借用《微服务设计》中的一句话：“你越不了解一个领域，为服务找到合适的界限上下文就越难……服务的界限划分错误，可能会致使不得不频繁地更改服务间的协做，而这种更改为本更高……”

4、SOA和微服务

　　因为SOA和微服务有千丝万缕的关系，这里简单罗列双方的对比图，算是一个小知识点：

　　

　　两种架构背后的意图是不一样的：SOA尝试将应用集成，通常采用中央管理模式来确保各应用可以交互运做。微服务尝试部署新功能，快速有效地扩展开发团队。它着重于分散管理、代码再利用与自动化执行。

5、总结

　　最后让咱们回顾一下前人经典的话语：

• 分布式第必定律是“尽可能不要使用分布式”。
• 软件行业从业者，尤为是那些已经不写代码的从业者，总会指望有银弹，但银弹终究是没有的。
• 微服务依赖于“基础设施自动化”。微服务不是“银弹”。

　　仍是回到咱们架构设计的原则上，遵循简单，适用，演化的原则，那么你的抉择也许会变得没有那么使人纠缠。

文章引用

• 从单体式架构迁移到微服务架构
• 《微服务设计》做者: [英] Sam Newman 出版社: 人民邮电出版社
• 4 Challenges You Need to Address with Microservices Adoption
• 为何使用微服务？