开发者社区 > 博文 > 企业微服务化势在必行,这样改造保你事半功倍
分享
  • 打开微信扫码分享

  • 点击前往QQ分享

  • 点击前往微博分享

  • 点击复制链接

企业微服务化势在必行,这样改造保你事半功倍

  • 京东科技开发者
  • 2020-09-11
  • IP归属:北京
  • 101520浏览

云妹导读:

微服务架构随着互联网的发展变得越来越重要,许多公司都开始或者已经转到了微服务架构,但仍然有大量公司对微服务抱着观望态度,还在考虑是否需要采用微服务架构。本文将通过一家企业架构的变迁来和大家一起探讨微服务架构能解决什么问题。


故事纯属虚构,如有雷同请对号入座!

 

你是否需要微服务架构?


大李是A公司的架构师,正在主导一款线上打车软件的架构,下面有好几个团队一起协作开发,已经忙了好几个月。

 

但大李最近有点烦,因为他主导的这个打车软件出现了很多问题,进展很不顺利。竞争对手D公司不断推出新功能,大李的团队只能疲于跟随,同时还得应对内部的各种问题。他感觉很疲惫,决定找公司技术总监老张聊聊。

 

一走进老张办公室,大李便开门见山地说:“张总,我们目前的开发速度很难跟上竞争对手的步伐。想找您聊聊看怎么做才能加快我们的进度?”

 

“好啊,那你能把我们现在的架构先拿出来看看吗?”老张答道。

 

于是,大李向老张展示了下面的架构图:


1.png

▲Figure 1 – A公司打车软件架构▲

 

老张仔细看了看后说:“目前我们的软件架构已经做了数据存储分离,并且把计算模块和存储模块都搬到了京东智联云上,用虚拟机来代替物理机。我们的计算单元也可以做横向扩展来应对高峰流量,架构已经很灵活了,那么现在面临的问题是什么呢?”

 

大李思索了一下娓娓道来:“我们现在面临的问题很多,我印象最深刻的大概有这几类:

 

一、发布困难:我们的计算单元和存储单元是需要分布在三个办公地点的六个团队共同合作,所以每次发布版本都会是一个艰难工作。需要高级别的管理人员来统筹发布计划,上次发布就是由您来统一指挥规划的。

 

一个模块的微小问题都可能会导致整个项目延迟,而现实中每个模块都会出现问题,所以通常要准备多轮回归测试来保证所有模块都没有大问题。上次就是小王最后合并进来的计费模块的代码居然影响了客户管理模块,然后大家拼命加班测试修复问题仍然延迟两天交付。

 

如果任何一个模块出现了问题,都需要整个应用一起调试,再发布上线。而每个新版本发布都会很困难,导致很多小问题的修复都要等很长时间。

 

二、模块之间依赖问题:很多模块都在一台虚拟机中运行,它们之间的依赖关系错综复杂。所以各个模块的启动顺序非常关键,必须十分小心地排列,而每次模块改动都可能导致启动顺序的更改。启动顺序的问题几乎每次发布新版都会有问题。

 

三、模块之间优先级问题:同样因为每个模块都在同一台虚拟机中运行,它们运行的线程优先级会变得非常敏感,需要非常小心地来设置优先级。否则在并发量大的情况下,互相之间抢占CPU资源会导致某些模块得不到CPU资源处理的情况。为了调整线程优先级,各个团队花了大量时间来测试和制定各个线程的优先级,但仍然不能在所有情况达到预期效果。

 

四、扩容难:在并发量大的情况下,某些处理单元可能需要扩容。那么扩容的机器上必须复制所有的模块。如果任何一个模块在扩容过程中出现问题,扩容就会失败。不需要的模块进行扩容本身就是一种浪费,并且增加了不必要的风险。

 

所有模块的数据都存在同样的存储节点中,使得计算节点和存储节点的关系变得非常复杂且难于管理。

 

五、难于维护:因为整个系统变得非常庞大复杂,各个模块的关系又错综复杂。现在几乎没有人能对整个系统的各个部分都了解,导致每次改动(新功能或者修复bug)都有可能直到最后才发现有没考虑到的情况,加剧了发布的延迟。如果再发生核心人员的离开,将会使这个情况雪上加霜。上次老金的离职就是个有力证明,他负责的模块虽然接替的人还比较熟悉,但是和别的模块的关系很复杂,结果是修复了一个bug,却引入了两个新bug。

 

综上所述,我认为必须改变我们的架构,让架构更简单,模块之间更独立,更易于维护、发布和扩容。”

 

 “你说的这些问题其实我也意识到了,最近我正在研究微服务架构和各种微服务平台。”老张点点头表示赞同:“根据我初步的研究,如果想解决上述那些问题,就要考虑向微服务架构演进。微服务应该能解决我们的大部分问题并且能提高我们的生产力。我给你推荐一篇文章,你可以先研究一下,回头我们再细致讨论。”

 

微服务小白扫盲:《微服务的理想与现实》

 

大李听到老张的回答,一下子转忧为喜:“那太好了!我先回去研究研究。过几天再找您讨论。”

 


微服务架构带来的好处和挑战


一星期后,大李又找到了老张:“张总,我仔细研究了微服务的理论和框架。按照我的理解,我们的架构如果能演变成这张微服务架构图,就差不多能解决我们目前面临的问题。”

 

大李一边说着,一边给老张展示他画出的微服务架构图:


1.png

▲Figure 2 – 微服务架构图▲

 

从架构图可以看出,基本上原来所有的模块都变成了松耦合的微服务,它们都可以进行独立部署、发布、扩容所有困扰我们的发布难、扩容难、模块CPU资源竞争问题、模块依赖问题全都可以解决。这样我们每个微服务可以独立发布新版本,新功能的发布和bug修复的流程都会快很多。”大李眼睛闪着光,兴奋地说道。

 

“同时,独立部署后也不再需要进程管理模块,各个微服务也不必共享基础架构模块,可以根据自己的需要来选择技术。另外因为各个服务现在界限清晰,每个微服务负责的功能相对简单内聚,开发人员很容易理解单个模块内部逻辑,所以维护难问题也可以得到很好解决。”大李继续补充着。

 

老张的脸上露出了满意的笑容:“那看起来我们的问题都得到了解决。另外我们公司已经开始使用敏捷开发,组建了scrum团队,并且我们有了Devops的经验。所以三地的各个团队可以变成独立的scrum团队,负责独立的微服务,这样人员之间的协同工作问题也可以得到解决。那我们是不是可以立刻开始微服务化了呢?”

 

大李的眉头又皱了起来,难为地说道:“张总,虽然微服务化很好,我们肯定要朝着这个方向演化。但是微服务也会给我们带巨大的挑战。”

 

“嗯,天下肯定没有免费的午餐。”老张随即问道,“说说看,我们的挑战主要是什么?”

 

大李早已调研清楚,为老张一一分析:“首先,我们需要把现有的应用拆分成多个微服务。这是我们的业务内容,非常关键,需要我们自己慢慢来做。但是微服务架构本身有很多的东西,比如这张服务注册发现图,如果我们采用springcloud架构,我们集成后需要自己部署维护注册中心。而注册中心集群也必须是高可用的。如果我们自己来部署维护注册中心集群,那这就是我们的短板,因为我们没有eureka或者consul的专业知识,部署和后期的运维工作都将需要更多的工程师。这将大大增加我们的成本,我们的组织结构也会更复杂。”


1.png

Figure 3 – 服务发现图

 

 “除了注册中心,还有别的关于微服务基础架构的问题吗?”老张问。

 

大李思考了一下回答道:“还有不少问题,比如我们拆分成微服务后,很多服务之间的调用分析是非常需要的东西。所以就需要调用链分析,这将让我们面临同样的问题。比如我们使用jaeger来作为调用链分析,那么就像调用链这张图展示的,我们也需要来维护复杂的jaeger集群,并且要做到高可用。”

 

1.png

Figure 4 – 调用链(来自jaeger官网)

 

大李又打开了一张微服务网关的架构图,指给老张看:“另外一个就是微服务网关。我和团队讨论了,微服务化还是要一步一步来。先把不重要的服务微服务化,一步一步演进,随着我们不断学习,再把重要的模块微服务化。这样风险会比较小。所以我们需要微服务网关来把微服务化的服务暴露给没有微服务化的应用。例如我们可以先把通知服务微服务化,别的核心逻辑不变,可以通过微服务网关来调用微服务化的通知服务。这样我们又需要维护微服务网关集群了。”

 

1.png

Figure 5 – 微服务网关

 

“另外,我们也需要配置中心集群来进行配置管理。我们还需要快速部署我们的应用到虚拟机上。需要控制台来进行应用部署、配置、以及服务治理如鉴权路由等管理。”大李继续补充。

 

老张听完大李的介绍后陷入沉思:“你说的这些非常对,看来微服务化还是给我们带来了很大的挑战。比如微服务网关确实我们需要考虑慢慢演进架构,来保证服务的稳定性。所有这些都由我们自己去培养团队搞,短期看来不太现实啊,更重要的是我们更应该专注于我们自己的服务而不是微服务的基础设施。”

 

“那有没有现成的微服务平台呢?能替我们解决这些问题,而我们自己只专注于自己的业务呢?”大李问。

 

“这个问题非常好,我听说京东智联云推出了一个JDSF微服务平台,你可以研究研究。我大概看了一下,感觉应该能满足我们对微服务基础架构的需求。”老张一边建议,一边打开了京东智联云的JDSF产品页给大李看:

 

1.png

扫码了解京东智联云 JDSF

 

大李眼前一亮:“好,我这就去研究一下。”

 


京东智联云JDSF如何快速实现微服务化?


两天后,大李兴冲冲来到老张的办公室:“张总,我仔细研究了京东智联云JDSF,这个平台完全能解决我们目前对微服务基础架构的要求。我总结了一下,主要有以下几点:

 

  • JDSF有注册中心和配置中心/调用链分析/和微服务网关,全部由京东智联云来帮助我们部署和进行后期维护,并且保证高可用。

  • JDSF支持SpringCloud、Dubbo、JSF,我们可以选择其中的任何一个,只需要把JDSF SDK集成进来就可以。

  • 我们可以上传jar/war包,然后JDSF可以帮助我们部署在虚拟机上,并且支持滚动部署。

  • 在微服务控制台上,可以轻松进行配置管理和服务治理的管理(如鉴权和路由)。就像这个路由图展示的,我们可以进行灰度发布。


1.png

Figure 6 – 路由

 

有了这套方案,这样我们就可以轻松使用微服务架构来改造我们的应用了。”

 

大李兴奋地继续介绍他的想法:“这样我们整个架构就会演进到这个最终架构,这里面灰色的部分都是京东智联云JDSF帮我们做的事情。而我们只需要关注自己的业务逻辑就可以了。完成了这套架构,我们就能快速发布新功能,集中精力和D公司在市场上PK。”


1.png

Figure 7 – A公司最终架构图

 

“太赞了!我从京东的朋友打听到他们内部的协同办公平台也在用这套微服务平台,京东可是有几十万员工在使用这套协同办公软件的。相信我们也能很快集成完毕的。”老张当下拍板,安排大李立即开始同京东智联云一起进行微服务改造。

 

后记


你的公司是否也面临着大李和老张一样的问题?当一个非常复杂的应用需要快速快速响应市场,需要有动态扩容能力,而应用本身面临不能快速发布、难于维护等问题,进而不能适应需求时,就需要考虑微服务架构来解决问题。

 

但需要注意的是,微服务架构虽然能解决问题,但同时也带来了架构层面的复杂性,并且需要微服务基础设施的支持,所以也将为企业架构带来巨大的挑战。

 

京东智联云JDSF微服务平台正是为了满足微服务化的简单可行,而提供了基础组件以及服务治理、应用管理等功能,可以极大简化企业微服务转型并且规避架构转化中的风险。如果你也对JDSF微服务平台感兴趣,不妨点击阅读来试用吧。