当下微服务是真的火啊！真是感觉现在在IT圈混的说自己不懂微服务都OUT了。放眼当前的大环境，大到各种大大小小的厂商产品介绍，小到漫天乱飞的招聘信息，微服务这个词总能在你的眼前飘来飘去。
说真的，微服务这个词真是让人又爱又恨。爱的是凡打上了微服务架构的标签，不管内部构架如何，产品立马让人觉得高大上了，逼格更高了（潜台词：能卖个好价钱）。然而让人恨得是，让我们架构师自己扪心自问，我们的产品当前做微服务架构是最优的产品架构吗？这其中的答案可能每位架构师都有自己的答案，或者也各自有各自的无奈。
好了，这个问题就此打住。既然我们的产品导向是要做微服务架构。那么，基于我们的产品应该如何来拆分呢？下面就和大家讨论交流一下。
什么是微服务
微服务（英语：Microservices）是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic）的API集相互通信。微服务是一种以业务功能为主的服务设计概念，每一个服务都具有自主运行的业务功能，对外开放不受语言限制的 API (最常用的是 HTTP)，应用程序则是由一个或多个微服务组成。
微服务是对比于单体应用来讲的。单体应用表示一个应用程序内包含了所有需要的业务功能，并且使用比如C/S架构（Client/Server）或是多层次架构（N-tier）实现。虽然它也是能以分布式应用程序来实现，但是在单体式应用内，每一个业务功能是不可分割的。若要对单体式应用进行扩展则必须将整个应用程序都放到新的运算资源（如：虚拟机）内，但事实上应用程序中最耗费资源、最需要运算资源的仅有某个业务部分（例如跑分析报表或是数学算法分析），但因为单体式应用无法分割该部分，因此无形中会有大量的资源浪费的现象。
微服务运用了以业务功能为关注点的设计理念，应用程序在设计时就能先以业务功能或流程设计先行分割，将各个业务功能都独立实现成一个能自主运行的个体服务，然后再利用相同的协议将所有应用程序需要的服务都组合起来，形成一个应用程序。若需要针对特定业务功能进行扩展时，只要对该业务功能的服务进行扩展就好，不需要整个应用程序都扩展。同时，由于微服务是以业务功能导向的实现，因此一个微服务不会受到其他应用程序的干扰，微服务的管理员可以视运算资源的需要来配置微服务到不同的运算资源内，或是部署建新的运算资源并将它配置进去。
总结一下，简单的来说微服务就是以业务为导向，将原有的单体应用拆分成多个服务单元。每个单元之间互不影响其内部状态，并通过共同认可的协议进行通信的架构设计。下面我们来讨论一下如何将一个单体服务拆分成多个业务单元。
微服务拆分的10条准则
用有限的上下文和普适语言来审视您的业务领域：
在进行分解之前，首先要做的是缩小产品所有者与开发人员之间的理解差异。一般产品所有者可能不了解技术术语，技术团队可能不了解术语在业务和业务解释方面的重要性。他们就像一个葡萄牙人用葡萄牙语和一位说英语的美国人交谈：两人之间没有人能理解对话的内容。因此，为了消除这些认知上的差距，我们需要采取以下步骤：
- 与产品所有者进行讨论：“业务目标是什么？”、“特定功能中的参与者是谁？”、“他们在定义功能时使用了哪些术语？”。在这些每个步骤上，都要提出更多问题，直到您弄清楚冲突的术语是什么为止，例如“订单上下文客户”与“基础结构支持上下文客户”是不同的。
- 一旦理解了冲突的术语并结合了相关功能，请制定一个上下文，以便在每个上下文中的每个域名的实体名称都是清晰的。
- 为每种情况定义一种通用语言，以便业务团队和技术团队在交流时可以使用一种通用语言进行沟通交流。
- 从一个粗粒度的有界上下文开始。如果以后有令人信服的理由进行划分，则划分有界上下文。如果有商业原因，我建议不要这样做。
确定核心领域并应用创新的点子：
核心域是为您的业务带来收益的领域。就在线购物而言，购物车模块是核心领域，它为从企业到消费者的买卖（B2C）平台提供了核心功能。了解您的核心模块，并思考如何改进这些竞争对手没有的模块。任何自动化或创新都会增加优势并增加您的收入，因此请注意：应该在核心领域进行研发和投资，以保持竞争优势。
对通用域进行成本优化：
通用域就是该领域中每个企业所共有的领域。对于这些领域，市场上不同的第三方厂商已经提供了不同的、相对成熟的商业化解决方案。比如您产品中的通知模块或广告活动模块。所以最好的策略是不要花任何钱在内部项目上创建该模块来重新发明轮子，除非您有一些令人信服的理由。一般情况下以便宜的价格采用第三方解决方案是比较好的选择。
考虑支持领域：
核心域需要支持域的帮助来丰富自身，并且在某些情况下，支持域也是可以带来收益的，并且将来有可能孵化（转变）成为核心域。因此，重要的是要思考并做出合适的决定：在支持领域进行投资，以便它可以产生收入。比如，在购物车域中，库存管理是支持领域，但投资研发-识别客户订单最近库存位置的算法，对降低运输成本也很重要。
引入反腐层（Anti-Corruption Layer）：
反腐层（Anti-corruption layer，简称 ACL）介于新应用和旧应用之间，用于确保新应用的设计不受老应用的限制。是一种在不同应用间转换的机制。
创建一个反腐层，以根据客户端自己的域模型为客户端提供功能。该层几乎不需要对其进行任何修改就可以通过其现有的接口与另一个系统进行通信。因此，反腐层隔离不仅是为了保护你的系统免受异常代码的侵害，还在于解耦不同的域并确保它们在将来保持解耦的状态。
反腐层是将一个域映射到另一个域，这样使用第二个域的服务就不必被第一个域的概念“破坏”。
实际上，我们经常遇到基于大型机或任何其他语言构建的旧系统。我们无法拆分该系统，但是还需要使用旧应用的数据。因此，在旧应用和微服务通信之间创建反腐层会是一个好主意。
另外，我们还需要考虑到通用领域。因为他们是不受开发团队控制的任何外部系统(第三方系统)
，因此也需要引入一个反腐层，该层将微服务与外部AP隔离开来，充当微服务和第三方之间的翻译者。并且还有一个用途是，它还可以帮助你在将来接入其他的任何第三方库（服务）。
识别数据通信模式：
一旦已经基于功能拆分了微服务，并且核心服务也封装了它们自己的数据库/持久层。那么接下来我们要考虑的问题是，您的UI视图/组件之间是如何进行通信的。是异步？还是同步？例如，对于一些系统，用户可以执行部分功能并创建中间状态，另一个系统对中间状态采取措施并回调或通知用户。
引入事件驱动架构（EDA）：
在实时应用程序中，您的业务案例可能具有复杂的工作流，并且根据数据的状态（基于状态变化）在工作流上具有许多分支。每个工作流程分支都可能采取不同的策略。因此，如果您考虑通过Rest API公开所有内容，那么你将会看到这些API创建出了一个非常复杂的通信网络。
因此，我们需要一个干净整洁的架构，其中每个微服务都可以独立运行而不会产生耦合。这里事件驱动的架构将会起着至关重要的作用，每个事件都包裹着状态的变化，并且微服务的设计遵循发布订阅(pub/sub)模型。因此一个微服务会发布以事件的形式包装的数据，其他微服务会侦听该事件。由于事件是不可变的，因此它也保存了实体或聚合器的历史记录。
使API简洁明了
在微服务中发布API时，请确保你的API不会将内部状态发布出去。发布API是一种使其他服务可以获取足够的信息以继续其流程的方式，因此要虑封装和网络调用，不应多次返回以获取派生信息。还要考虑事件，应该发布哪些事件以及哪些事件必须保留在内部。也许你可以发布一个粗粒度事件，而不是发布一个个内部的小事件。
例如，你有地址更改事件和个人信息更改事件。最好是发布一个名为CustomerUpdateEvent的粗粒度事件，而不是提供两个独立的事件。
将相关的微服务合并为更大的服务：
拆分之后，当需要添加或更新功能时，你会遇到一些微服务总是一起变化的情况。这时候，你应该知道你已经以错误的方式拆分了它。它们一定不能被隔离到一个小型服务中，它们是同一逻辑单元的一部分。因此，将它们合并为一个服务是明智的，这将减少不必要的网络通信开销，和降低模块间的复杂度。
引入无缝开发支持工具：
微服务不是免费的午餐。如果你采用微服务，那么首先要做好准备，因为微服务是分布式的，因此要投资一些软件工具，以此来扩展弹性和提高可用性，并缩短产品投产时间，帮助尽早发现故障等。
因此，请在CI/CD流水线上投入一定的资金资源。采用云基础架构，使用跟踪工具，使用日志聚合器来搜索日志，使用混沌工程测试你的系统，等等。
最后
以上就是10点我们要做微服务拆分时的一点想法和建议，至于对错，本人也没有一个肯定的答案。但是，盲目跟进微服务架构，个人觉得其实不是一个很好的现象。
一个产品诞生的起因本身就是为了解决一系列实际的业务问题，结合业务实际来构建一个合理的技术架构才是一个最好的选择。当然，有些朋友可能会觉得微服务架构有那么多单体架构没有的有点，我可以提前布局以应对业务量上去之后的系统瓶颈。但是，每个产品都有自己的生命周期，每个产品也都有自己的业务特点。另外更要命的是，谁也无法预测未来，需求也是在不断的快速变化，有时候提前布局到的东西可能永远也用不上，这就白白浪费了前期的投入，反而得不偿失。您觉得呢？当然，如果有其他外力因素不能左右那就另说了。
欢迎关注我的公众号 须弥零一，跟我一起学习IT知识。
如果您喜欢此博客或发现它对您有用，则欢迎对此发表评论。 也欢迎您共享此博客，以便更多人可以参与。 如果博客中使用的图像侵犯了您的版权，请与作者联系以将其删除。 谢谢 ！