漫谈何时从单体架构迁移到微服务?

面对微服务如火如荼的发展,很多人都在了解,学习希望能在自己的项目中帮得上忙,当你对微服务的庐山真面目有所了解后,接下来就是说服自己了,到底如何评估微服务,什么时候使用微服务,什么时间点最合适,需要哪些技术储备和资源投入等等,这些都是你需要面对和解决的。 本文从单体架构,微服务架构,微服务风险评估,微服务落地条件等几个方面探讨微服务的落地过程,希望对你有所启发。

讲解微服务之前,我们先简单了解下单体架构。

一、单体架构

单体架构的优点:

  • 快速开发和验证想法,证明产品思路是否可行
  • 投入资源和成本,包括人力和物力相对比较节约

单体架构的缺点:

随着业务的复杂度增加,单体的灵活度会逐渐下降,比如:

  • 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。

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

三、何时采用微服务?

1、杨波说

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

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

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

“交叉点表明,业务已经到达了一定的复杂性,单块应用已经无法满足业务增长的需要,研发效率开始下降了,而微服务可以提升研发和交付的效率。这个点需要架构师去综合,权衡。个人经验,一般团队需要达到百人规模,才去考虑微服务。”

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

“一般情况下,这个时候就需要大规模地扩张开发人员,以支撑多个功能的开发。如果这个时候继续采用单体应用架构,多个功能模块混杂在一起开发、测试和部署的话,就会导致不同功能之间相互影响,一次打包部署需要所有的功能都测试 OK 才能上线。

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

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

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

2、微服务落地条件评估

一般情况下,业务系统引入新技术就必然会带来架构的复杂度提升,在具体决策前,你先要认识到新架构会带来哪些新的问题,这些问题你和你的团队是否能够解决?如何解决?是自己投入人力建设,还是采用业界开源方案?假如你和我一样都是微服务的旁观者或者学习者,那么下面的评估也许对你又所参考。

  • ① 落地方式选择 不同的落地方式决定不同的资源配置。 方式一:借力外部架构咨询公司提供架构DEMO和培训服务助推内部团队技术转型升级。 方式二:招聘相关经验丰富的人员进来,自行研究和搭建架构并做内部培训,推动团队技术升级。 建议:如果比较紧急,采用第一种方式,因为招聘匹配的人才比较困难,等不起。但是不管是那种方式,对于团队来说都需要一定的技术人才储备方便后续交接和运维。
  • ② 人才储备 这里分成两类人员,一类是研究型,一类是应用型。研究型主要是以技术攻坚为主,负责微服务的核心组件的研究和开发,比如服务发布和订阅,服务跟踪和监控,服务的治理;应用型主要是负责技术理解应用为主。
  • ③ 技术储备 微服务相关技术栈和微服务周边技术栈。周边技术栈包括领域驱动涉及,持续交付,分布式至少,负载均衡,CAP理论,缓存原理,DevOps和容器化技术。
  • ④ 团队规模评估 杨波在给微服务的开发团队规划时候给了一个百人左右的大概预估,至于到底需要多少开发人员就没有细说,可能作者本身呆过的公司都是大厂,对人力成本控制没有那么大的包袱,对于中小企业,人力是最贵的成本。如果要一定要上微服务,该怎么办? 对于微服务的团队规模众说纷纭,有的说要百来号人;有的说需要精兵10人左右;有的说和人数没有关系,只和业务有关;有的说一个懂微服务的架构师也能搞定。这些说法都比较笼统,如果你想上微服务,人力评估包括人力、能力、人数等等,这些因素还是非常重要的,毕竟成本才是商业的本质,有可能不客观的规划会导致项目的溃败。 对于微服务的团队规模是哪些方面决定的呢?我觉得至少要从以下两个维度来评估: 业务规模:如果你们的业务架构非常复杂,有仓储系统开发,ERP系统,OA系统,订单系统等等,业务越多,需求人数越多(这里人数指的都是后台开发人数)。 技术能力:另外,别忘了非功能性的开发,比如API网关,服务跟踪、治理等也是需要人去开发和维护的,这些非功能性的核心组件需要多少人,由于没有完整的开发经验,加上个别组件,比如跟踪系统,开发的程度可深可浅,开发周期可长可短,以目前个人的经验还无法给与合理的建议。可能牛人1个人两周就够了,也可能高级开发2个人,一人分工三个核心组件,两周也够用。或者架构外包,只要交接的人能跟上,也是一种解决方案。 总结:1个精通微服务落地经验的架构师是必不可少的,围绕架构师周边一帮高级开发,按根据实际业务来确定,一般一个开发负责2-3个核心模块,不宜太多,比如目前核心模块有8个,对应人数配置大概在3-4个左右。

3、转微服务风险评估

  • ① 重写面广 由于是架构级别的调整,之前能保留下来的大部分是解耦比较好的代码,比如前端代码,采集服务代码,部分业务逻辑代码,所以对现有框架冲击面比较大。
  • ② 复杂度高 因为微服务是一种观念和思想,又是新近技术,本身就有各种架构实现方式和技术解决方案。所以对技术人员来说,对比选型本身就是一个考验。加上本身涉及的技术面就比较广,所以复杂度和门槛相对比较高。 但是该技术发源于亚马逊,经过近些年的发展,虽然还在发展,但是已经相对成熟。
  • ③ 人员配置 微服务架构工作量主要集中在后端,对后端开发人员的技术级别有较高的要求,主要是对微服务原理和开源组件的熟悉上,同时需要具备整体的微服务的意识。暂时不具备整体微服务开发意识和经验,需要通过培训后进行转型升级。
  • ④ 合作方式 如果采用借助外部架构力量来助推架构升级,和架构单位的合作就不是简单的外包,涉及的面会变得比较广,在完全交接过来之前,周期会比较长。包括对我们业务架构的深入了解,然后根据业务架构绘制可靠技术架构蓝图,再根据技术蓝图进行落地实施(不建议只提供架构方案而由其他单位实施落地),包括新系统的开发,旧系统的升级,当然这种升级是平滑过度的,对业务窗口并不会产生影响。

4、合理的拆分姿势

如何正确拆分?这里正确指的是合理,因为没有绝对的标准。按照前人的经验可以分为纵向和横向两种划分方法:

  • ① 纵向拆分 是从业务维度进行拆分。标准是按照业务的关联程度来决定,关联比较密切的业务适合拆分为一个微服务,而功能相对比较独立的业务适合单独拆分为一个微服务,比如上图中的订单服务,用户服务。另外粒度太小,服务聚合是一个坑,粒度太大,分和没分一个样。
  • ② 横向拆分 是从公共且独立功能维度拆分。标准是按照是否有公共的被多个其他服务调用,且依赖的资源独立不与其他业务耦合。比如上图中的元数据服务和消息服务。
  • ③ 总结 借用《微服务设计》中的一句话:“你越不了解一个领域,为服务找到合适的界限上下文就越难……服务的界限划分错误,可能会导致不得不频繁地更改服务间的协作,而这种更改成本更高……”

四、SOA和微服务

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

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

五、总结

最后让我们回顾一下前人经典的话语:

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

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

-END-

原文发布于微信公众号 - 纯洁的微笑(keeppuresmile)

原文发表时间:2019-01-09

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券