一文读懂企业如何落地微服务,循序渐进5步走

近来,企业转向微服务架构已经成为一个非常火热的话题,但是如何将微服务在企业中落地很多人不得其解,今天数人云带来的文章,就从循序渐进5步走的方法阐述企业级落地微服务的模式,同时也带来了向微服务转型从团队角度的一些思考。

Markdown

微服务架构(MSA)正在重塑企业IT生态系统,它最初只是一种机制,将大型单体应用程序分解为一组独立地、功能集中的应用程序,这些应用程序可以独立地设计、开发、测试和部署。MSA的早期采用者运用这种模式来实现其后端系统或业务逻辑,一旦他们实现了这些所谓的后端系统,就有了在整个董事会中实现相同模式的想法,本文主要讨论可以在微服务驱动的企业总可以使用的解决方案模式。

企业向微服务转型的5步走

如果从上往下看,企业IT系统看起来就如下图所示:

Markdown

如图所示,系统由水平和垂直的多层组成,业务逻辑将在后端系统中作为单片应用程序实现,并且将有像ERP、CRM等第三方系统,在后端系统之上,有一个集成层,将异构后端系统连接在一起,一旦这些服务被集成,就需要通过API管理层作为托管API公开为内部和外部用户的API,安全性和分析将在所有者三层中使用,随着微服务的引入,这个完整的生态系统得到了解决方案模式,可以满足不同企业的需求。

MSA(微服务) BE + Monolithic ESB + Monolithic APIM

这是微服务实现的最常见和最开始的模式,其中后台系统(业务逻辑)是作为微服务开发的,同时保留其他层。

Markdown

上述模式是任何企业引入微服务(MSA)并评估方法利弊的良好七点,基于此方法的结果,可以通过移动到下面提到的模式来实现更广泛的应用。

Monolithic APIM + Service Mesh + 消息代理

微服务最新的发展趋势是“服务网格(Service Mesh)”的概念,它提供了微服务间通信所需的附加功能,消息代理(Message Broker)被用作跨微服务的消息交换的通信通道(Dumb Pipe)这将减少在某些用例中集成层的需求。

Markdown

如上图所示,在这个解决方案模式中,MSA已经扩展到了集成层,并消除了单独集成层的需要,尽管这个模式可以在一个绿色的IT企业中实现,但对于拥有这么多附加系统的大型企业来说将会更加困难。

Monolithic APIM + Micro Integration + 服务网格

模式2中的一个挑战是将CRM,EPR系统集成到微服务层,与其在微服务层或Message Broker中进行集成,还可以引入一个微集成层来满足这一需求,与此同时,Message Broker功能(消息传递通道)也可以移动到微集成层中。

Markdown

服务无网格+微集成+Edge网关

随着企业内部的微服务体系结果的广泛采用,Monolithic APIM也可以被微API网关或Edge网关所替代,这是可以实现的下一个解决方案模式。

Markdown

在此模式中,基于向用户公开的API部署了一组Edge网关,从而替换了单一的API管理层,当设计到设计、开发、测试和部署时,这些边缘网关与微服务的行为类似,同时提供API管理功能。

全面转向微服务

一旦微服务全面铺开,安全性、分析和数据层也可以作为微服务去实现,除了COTS系统,整个企业IT生态系统作为微服务在这个解决方案模式中实现。

Markdown

基于上图,企业中的所有组件除了第三方系统,都是作为微服务来实现的,这种模式可以扩展,这样服务网格就可以扩展到微集成、分析、安全性和数据库微服务。

通过前文我们可以看到,一个企业向微服务转型所经历的是循序渐进的,而不是一蹴而就的,因为尽管开放源码技术,如Docker、Kubernetes、Prometheus和集群使得企业采用微服务架构比以往任何时候都要容易,但让团队在微服务上保持一致仍然是一个困难的挑战。

微服务没有本质上的“微”,有些可以很小,但大小是相对的,在企业中没有标准的度量单位,一个公司的“小服务”可能是100万行代码,而在另外一个公司,也许就是1万行。

有些人认为微服务根本就不是新出来的概念,而是面向服务的体系结构(SOA)的重新命名,但另外一些人认为微服务是SOA的一个实现,类似于Scrum是如何实现敏捷的。

在没有精确定义的情况下,如何让团队在与微服务相同的统一性上?在谈论微服务时,最重要的事情是确保团队以一个共同的起点为基础,模糊的定义不能帮助团队,就如同试图将敏捷实现到实践当中去,却又没有上下文之间的关联关系。

以下是本文作者关注的三个领域,以及微服务实现中吸取的教训。

1 能够更快地使用软件

作者的主要应用程序是一个大型的代码库,有几个小团队的开发人员试图为不同的目的构建特性。这意味着每一个改变都必须试图满足所有不同的群体。例如,只提供一个组的数据库更改必须由其他组进行审查和接受,而其他组没有那么多上下文。这很乏味,所以慢了下来。

拥有不同的开发人员组共享相同的代码库,这也意味着代码在不经过深思熟虑的情况下会持续地变得更加复杂。当代码库变得更大时,团队中没有人能够拥有它,并确保所有的部件都是有组织的,并以最佳的方式组合在一起。这让部署变得可怕。对应用程序的一行更改需要部署整个代码库,以推动更改。由于部署大型应用程序是高风险的,因此质量保证过程得到了增长,所以部署的更少。

通过微服务体系结构,希望能够将代码划分为不同的开发团队,这样开发人员可以完全拥有自己的部分。可以使团队在没有繁琐的设计、审查和部署过程的情况下能够更快地进行创新。希望有更少的开发人员使用更小的代码库,使代码库更容易开发、测试。

2 灵活的技术选择

作者的主要应用程序是大型的,它与Ruby on Rails建立了一个自定义的JavaScript框架和复杂的构建过程。应用程序的几个部分遇到了主要的性能问题,这些问题很难修复,并导致了应用程序其余部分的问题。后来看到了一个机会,可以使用更好的方法重写应用程序的这些部分。代码库是交织在一起的,这使得重写感觉非常大,而且代价高昂。

与此同时,一个前端团队希望从定制JavaScript框架中撤出,并使用新的框架来构建产品特性。但是,对现有的应用程序和复杂的前端构建过程的混合反应似乎很昂贵。

随着时间的推移,团队越来越沮丧,因为他们觉得被困在一个太大、太昂贵、无法修复或替换的代码库中。通过采用微服务体系结构,希望保持单个服务的规模更小,意味着用更好的实现来替换它们的成本将更容易管理。也希望能够为每一份工作选择合适的工具,而不是被一刀切的方法所困。可以灵活地在不同的应用程序中使用多种技术。如果一个团队想要使用Ruby以外的其他东西来获得更好的性能,或者从定制的JavaScript框架中切换,都是可以做到的。

5 微服务可不是免费的午餐

除了概述希望实现的好处之外,还确保对与构建和管理微服务相关的成本和挑战保持清醒,看清现实。开发、托管和管理众多的服务需要大量的开销(并编排了大量不同的开源工具)。在少数几个流程上运行一个单一的代码库,可以很容易地转化成几十个服务的过程,需要负载平衡器、消息传递层和聚类来恢复弹性。管理所有这些需要大量的技能和工具。

此外,微服务还涉及到分布式系统,这些系统引入了大量的问题,如网络延迟、容错、事务、不可靠的网络和异步性。

总结

一旦定义了微服务的好处和成本,就可以讨论架构,而不会陷入关于谁做的微服务是正确或错误的反效果的争论中。能够更专注于试图解决的核心问题:

在接下来的6到12个月里,如何让更多的服务更快地帮助我们的软件? 在系统中使用特定的工具有很强的技术优势吗? 是否预见到想要用更合适的系统替换其中一个系统? 当雇佣更多的人的时候,我是如何构建团队的呢? 从拥有更多的服务中获得的生产力是否值得可预见的成本?

综上所述,这里有5个建议的步骤,可以让团队在进入微服务前进行调整:

了解微服务,同时同意没有“正确”的定义。 定义一个共同的目标,以避免适得其反的辩论。 讨论并记住采用微服务的预期收益和成本。 避免过于急切地想要将微服务一蹴而就,对于如何最好地架构系统,可以接受创造性的想法和热烈的讨论。 保持根植于队所发现的利益和成本。

其中核心重点是要确保团队有一个明确定义的共同目标来完成,更有价值的是讨论和定义想要实现的微服务,而不是试图确定微服务到底是什么。

原文作者:DzoneNodeXperts Blog 原文链接:https://www.tuicool.com/articles/quqeUfN