内容来源：本文由IT大咖说（ID：itdakashuo）转载自数人云公众号（ID：dmesos），感谢您的阅读。
阅读字数：2175 | 6分钟阅读
摘要
近来，企业转向微服务架构已经成为一个非常火热的话题，但是如何将微服务在企业中落地很多人不得其解，今天小数带来的文章，就从循序渐进5步走的方法阐述企业级落地微服务的模式，同时也带来了向微服务转型从团队角度的一些思考。
微服务架构（MSA）正在重塑企业IT生态系统，它最初只是一种机制，将大型单体应用程序分解为一组独立地、功能集中的应用程序，这些应用程序可以独立地设计、开发、测试和部署。MSA的早期采用者运用这种模式来实现其后端系统或业务逻辑，一旦他们实现了这些所谓的后端系统，就有了在整个董事会中实现相同模式的想法，本文主要讨论可以在微服务驱动的企业总可以使用的解决方案模式。
企业向微服务转型的5步走
如果从上往下看，企业IT系统看起来就如下图所示：
如图所示，系统由水平和垂直的多层组成，业务逻辑将在后端系统中作为单片应用程序实现，并且将有像ERP、CRM等第三方系统，在后端系统之上，有一个集成层，将异构后端系统连接在一起，一旦这些服务被集成，就需要通过API管理层作为托管API公开为内部和外部用户的API，安全性和分析将在所有者三层中使用，随着微服务的引入，这个完整的生态系统得到了解决方案模式，可以满足不同企业的需求。
一、MSA（微服务） BE + Monolithic ESB + Monolithic APIM
这是微服务实现的最常见和最开始的模式，其中后台系统(业务逻辑)是作为微服务开发的，同时保留其他层。
上述模式是任何企业引入微服务（MSA）并评估方法利弊的良好七点，基于此方法的结果，可以通过移动到下面提到的模式来实现更广泛的应用。
二、Monolithic APIM + Service Mesh + 消息代理
微服务最新的发展趋势是“服务网格（Service Mesh）”的概念，它提供了微服务间通信所需的附加功能，消息代理（Message Broker）被用作跨微服务的消息交换的通信通道（Dumb Pipe）这将减少在某些用例中集成层的需求。
如上图所示，在这个解决方案模式中，MSA已经扩展到了集成层，并消除了单独集成层的需要，尽管这个模式可以在一个绿色的IT企业中实现，但对于拥有这么多附加系统的大型企业来说将会更加困难。
三、Monolithic APIM + Micro Integration + 服务网格
模式2中的一个挑战是将CRM，EPR系统集成到微服务层，与其在微服务层或Message Broker中进行集成，还可以引入一个微集成层来满足这一需求，与此同时，Message Broker功能（消息传递通道）也可以移动到微集成层中。
上图可以看到，微服务、数据库系统和COTS系统（ERP、CRM）都是利用微服成层集成的。
四、服务无网格+微集成+Edge网关
随着企业内部的微服务体系结果的广泛采用，Monolithic APIM也可以被微API网关或Edge网关所替代，这是可以实现的下一个解决方案模式。
在此模式中，基于向用户公开的API部署了一组Edge网关，从而替换了单一的API管理层，当设计到设计、开发、测试和部署时，这些边缘网关与微服务的行为类似，同时提供API管理功能。
五、全面转向微服务
一旦微服务全面铺开，安全性、分析和数据层也可以作为微服务去实现，除了COTS系统，整个企业IT生态系统作为微服务在这个解决方案模式中实现。
基于上图，企业中的所有组件除了第三方系统，都是作为微服务来实现的，这种模式可以扩展，这样服务网格就可以扩展到微集成、分析、安全性和数据库微服务。
通过前文我们可以看到，一个企业向微服务转型所经历的是循序渐进的，而不是一蹴而就的，因为尽管开放源码技术，如Docker、Kubernetes、Prometheus和集群使得企业采用微服务架构比以往任何时候都要容易，但让团队在微服务上保持一致仍然是一个困难的挑战。
微服务没有本质上的“微”，有些可以很小，但大小是相对的，在企业中没有标准的度量单位，一个公司的“小服务”可能是100万行代码，而在另外一个公司，也许就是1万行。
有些人认为微服务根本就不是新出来的概念，而是面向服务的体系结构（SOA）的重新命名，但另外一些人认为微服务是SOA的一个实现，类似于Scrum是如何实现敏捷的。
在没有精确定义的情况下，如何让团队在与微服务相同的统一性上？在谈论微服务时，最重要的事情是确保团队以一个共同的起点为基础，模糊的定义不能帮助团队，就如同试图将敏捷实现到实践当中去，却又没有上下文之间的关联关系。
以下是本文作者关注的三个领域，以及微服务实现中吸取的教训。
团队角度微服务落地思考
一、能够更快地使用软件
作者的主要应用程序是一个大型的代码库，有几个小团队的开发人员试图为不同的目的构建特性。这意味着每一个改变都必须试图满足所有不同的群体。例如，只提供一个组的数据库更改必须由其他组进行审查和接受，而其他组没有那么多上下文。这很乏味，所以慢了下来。
拥有不同的开发人员组共享相同的代码库，这也意味着代码在不经过深思熟虑的情况下会持续地变得更加复杂。当代码库变得更大时，团队中没有人能够拥有它，并确保所有的部件都是有组织的，并以最佳的方式组合在一起。这让部署变得可怕。对应用程序的一行更改需要部署整个代码库，以推动更改。由于部署大型应用程序是高风险的，因此质量保证过程得到了增长，所以部署的更少。
通过微服务体系结构，希望能够将代码划分为不同的开发团队，这样开发人员可以完全拥有自己的部分。可以使团队在没有繁琐的设计、审查和部署过程的情况下能够更快地进行创新。希望有更少的开发人员使用更小的代码库，使代码库更容易开发、测试。
二、灵活的技术选择
作者的主要应用程序是大型的，它与Ruby on Rails建立了一个自定义的JavaScript框架和复杂的构建过程。应用程序的几个部分遇到了主要的性能问题，这些问题很难修复，并导致了应用程序其余部分的问题。后来看到了一个机会，可以使用更好的方法重写应用程序的这些部分。代码库是交织在一起的，这使得重写感觉非常大，而且代价高昂。
与此同时，一个前端团队希望从定制JavaScript框架中撤出，并使用新的框架来构建产品特性。但是，对现有的应用程序和复杂的前端构建过程的混合反应似乎很昂贵。
随着时间的推移，团队越来越沮丧，因为他们觉得被困在一个太大、太昂贵、无法修复或替换的代码库中。通过采用微服务体系结构，希望保持单个服务的规模更小，意味着用更好的实现来替换它们的成本将更容易管理。也希望能够为每一份工作选择合适的工具，而不是被一刀切的方法所困。可以灵活地在不同的应用程序中使用多种技术。如果一个团队想要使用Ruby以外的其他东西来获得更好的性能，或者从定制的JavaScript框架中切换，都是可以做到的。
三、微服务可不是免费的午餐
除了概述希望实现的好处之外，还确保对与构建和管理微服务相关的成本和挑战保持清醒，看清现实。开发、托管和管理众多的服务需要大量的开销(并编排了大量不同的开源工具)。在少数几个流程上运行一个单一的代码库，可以很容易地转化成几十个服务的过程，需要负载平衡器、消息传递层和聚类来恢复弹性。管理所有这些需要大量的技能和工具。
此外，微服务还涉及到分布式系统，这些系统引入了大量的问题，如网络延迟、容错、事务、不可靠的网络和异步性。
总结
一旦定义了微服务的好处和成本，就可以讨论架构，而不会陷入关于谁做的微服务是正确或错误的反效果的争论中。能够更专注于试图解决的核心问题：
在接下来的6到12个月里，如何让更多的服务更快地帮助我们的软件?
在系统中使用特定的工具有很强的技术优势吗?
是否预见到想要用更合适的系统替换其中一个系统?
当雇佣更多的人的时候，我是如何构建团队的呢?
从拥有更多的服务中获得的生产力是否值得可预见的成本?
综上所述，这里有5个建议的步骤，可以让团队在进入微服务前进行调整：
了解微服务，同时同意没有“正确”的定义。
定义一个共同的目标，以避免适得其反的辩论。
讨论并记住采用微服务的预期收益和成本。
避免过于急切地想要将微服务一蹴而就，对于如何最好地架构系统，可以接受创造性的想法和热烈的讨论。
保持根植于队所发现的利益和成本。
其中核心重点是要确保团队有一个明确定义的共同目标来完成，更有价值的是讨论和定义想要实现的微服务，而不是试图确定微服务到底是什么。
原文作者：DzoneNodeXperts Blog
原文链接：https://www.tuicool.com/articles/quqeUfN