漫谈何时从单体架构迁移到微服务?
面对微服务如火如荼的发展,很多人都在了解、学习,希望能在自己的项目中帮得上忙,当你对微服务的庐山真面目有所了解后,接下来就是说服自己了。
到底如何评估微服务,什么时候使用微服务,什么时间点最合适,需要哪些技术储备和资源投入等等,这些都是你需要面对和解决的。
本文从单体架构,微服务架构,微服务风险评估,微服务落地条件等几个方面探讨微服务的落地过程,希望对你有所启发。
讲解微服务之前,我们先简单了解下单体架构。
一、单体架构
单体架构的优点:
- 快速开发和验证想法,证明产品思路是否可行
- 投入资源和成本,包括人力和物力相对比较节约
单体架构的缺点:
随着业务的复杂度增加,单体的灵活度会逐渐下降,比如:
- IDE过载:随着代码量增加,代码整体编译效率下降。
- 规模化:无法满足团队规模化高效开发。
- 系统开发、测试、部署的冲突和效率低下等问题
- 只能关注一套技术栈
- 应用扩展性比较差
- 海量用户高并发访问数量有限
单体适用场景:
架构设计的三大原则告诉我们,架构需要的是简单、适度、演化。
对于项目起步阶段,单体是最高效也是最节省成本的方式。
因为初期阶段,由于人力,成本,业务熟悉程度,微服务技术积累等因素,如果过度设计可能工期和复杂度会急剧上升,造成交付困难,问题百出,从而错过了时间窗口。
最合适,简单的方式还是单体优先,这是创业公司的特点决定的。
当然设计面向微服务的单体架构也是一种聪明的方法,这遵守了系统演化的法则。
单体分层目的:
无论采取何种维度的架构分层,分层的最核心目的是保证各层之间的差异足够清晰,边界足够明显,为将来可能产生的变化提供最容易、最小化的修改。
比如客户端要从安卓替换为IOS,底层无须任何改动,就像替换积木一样。
又比如,设备需要接入新的设备或协议,其他层也不需要做任何变化,可以无缝平滑接入任何设备。
建议如果前期在业务不十分清晰,求的是验证想法,证明产品思路是否可行性,并且业务量不大,仅限于省级范围,建议只要对当前架构稍加改良升级就可以了。
这样改动量相对较小,且至少能支撑一定时间段的业务增长。
二、微服务架构
微服务的优势
支撑的业务更加庞大,可以支撑海量用户高并发和海量设备接入,支持分布式多机房,多区域部署,支持服务器无限扩容。支持私有云,公有云,混合云等部署方式。
所以微服务是大多数互联网公司的首选。
微服务的代价
技术门槛高:微服务包括,服务描述,注册中心,服务框架,服务监控,服务追踪,服务治理等几大基本组件,以上每个组件缺一不可。
每个组件展开又包括很多技术门槛,比如,容器技术,持续部署,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.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总结
借用《微服务设计》中的一句话:“你越不了解一个领域,为服务找到合适的界限上下文就越难……服务的界限划分错误,可能会导致不得不频繁地更改服务间的协作,而这种更改成本更高……”
四、SOA和微服务
由于SOA和微服务有千丝万缕的关系,这里简单罗列双方的对比图,算是一个小知识点:
两种架构背后的意图是不同的:SOA尝试将应用集成,一般采用中央管理模式来确保各应用能够交互运作。
微服务尝试部署新功能,快速有效地扩展开发团队。它着重于分散管理、代码再利用与自动化执行。
五、总结
最后让我们回顾一下前人经典的话语:
- 分布式第一定律是“尽量不要使用分布式”。
- 软件行业从业者,尤其是那些已经不写代码的从业者,总会期望有银弹,但银弹终究是没有的。
- 微服务依赖于“基础设施自动化”。微服务不是“银弹”。
还是回到我们架构设计的原则上,遵循简单,适用,演化的原则,那么你的抉择也许会变得没有那么令人纠缠。
更多信息来自:东方联盟网 vm888.com
- 09-29工作3年和工作7年的程序员到底差在哪里?
- 09-29身为网络工程师,你能说清楚网络的概念吗?
- 09-29IT运维没做好这一点,恭喜你,这个锅你背定了
- 08-01浅谈Web经典三层架构和MVC框架模式
- 08-01作为首席架构师,我是如何选择并落地架构方案的?
- 08-01互联网架构的演变,看了好多这个讲的确实清楚!
- 08-01架构师教你如何设计一个高并发系统?
- 08-01分布式系统中Session共享的五种方法
- 01-11全球最受赞誉公司揭晓:苹果连续九年第一
- 12-09罗伯特·莫里斯:让黑客真正变黑
- 12-09谁闯入了中国网络?揭秘美国绝密黑客小组TA
- 12-09警示:iOS6 惊现“闪退”BUG
- 11-01京东七鲜与前置仓完成融合
- 11-01美团外卖推出食安三大举措:抵制违规经营,
- 11-01微软:Windows 10将于2025年终止支持,建议
- 10-29同程旅行回应酒店订单“订后即焚” 将考虑是
- 10-29阿里国际站发布全流程AI产品 推进更高效经营