接触微服务已经五六年了。断断续续要么从头开始，要么半路接手，也经历过5套微服务项目。从这些项目的经验和与同行的交流来看，按照业务切分微服务的方法，思路一般并不复杂，但在实现中总是会遇到各种各样的问题。直到现在，我仍在探索实现最佳微服务的最佳方式。我在之前的文章中也提到过，一服一库是微服务最基本的模式，也讲了为什么要搞微服务。在今天的文章中，我想讲的是：一库一服最基本的模型实现的一般方法是什么。1、搞微服务可能是个政治问题。刚开始接触微服务的时候，真的是不得已。公司有一个庞大的体系，负责公司当时主要的盈利业务，这是非常非常重要的。但是，正因为它重要，所以才成为产品和业务团队重点服务的对象。这些人每天都在思考这个系统的业务，不断地对技术团队提出各种要求。需求不说，还需要技术快速迭代。一旦他们的需求不能及时上线，产品经理就会在各种会议上抱怨，说技术团队影响了速度，有被竞争对手赶上的风险。技术团队很无语，因为系统太大了，这么大的系统，真的很难改。至于原因，我在之前的文章中也说过了，不再赘述。出于这些原因，我们决定采用微服务。什么时候使用微服务？当你的交付时间对产品团队和运营团队都不够时，请考虑一下。还有，后来我做其他新项目的时候，领导觉得这个系统太简单了，没有自己的技术特点。不得已，我又把微服务拿出来了。领导看到后眼睛一亮，说好。因此，以我的经验，有时候搞微服务本质上是一个政治问题，而不是技术问题。总的来说，对于微服务的实现，并不是一个特别大规模的项目，微服务带来的收益也不是很大，但是工作量却增加了很多。不管是什么原因，我接触到的微服务越来越多了。为了用好微服务，我真正研究了微服务的架构，总结了自己在微服务分解实践中的一些经验。.首先，如果预估业务增长很快，那就不要犹豫，提前考虑微服务的拆分。其次，如果你在设计架构的时候发现你需要大量的异构技术栈，你也应该考虑微服务。最后，如果公司的技术基础设施很完善，相应的业务一开始就设计的很复杂，那么不要犹豫，入手微服务。2.迁移到微服务可以很粗糙，也可以很温柔。回过头来，继续讲我第一次从事微服务的经历。因为迁移微服务不是一蹴而就的事情，但是我迫切需要一些微服务部署简单、开发速度快的优势。所以，不得已，我想到了一个妥协的办法。我分析了一些急需实现的业务需求，发现这些需求大致可以分为以下两类：一些需求是一组独立的边缘服务，一些需求集中在核心业务的边缘。应该如此。业务和我们的技术一样。如果改变了核心业务的逻辑，一旦出现问题，他们将要承担很大的责任。但他们也想体现自己的价值，最稳妥的做法就是在核心业务的角落里捣鼓。知道了这一点，就会好办了。对于第一类独立的业务需求，我直接设计了一套独立的服务，让它可以通过网络与现有的老系统进行远程互联。这样新建的服务体积小，易于维护。以前的旧系统也成为新服务的服务。这样可以快速迭代一些需求。对于第二类需求，对原系统核心边缘的需求，我是这样做的。首先，我获得了领导的支持，优先剥离经常需要的业务模块。这样，一些不经常变化的业务模块还在老系统中。其实在这些时候，系统并没有那么大，能够满足业务偶尔的业务变更需求。那么在后续的时间里，我会慢慢抽空把剩下的一些业务模块剥离出来。但是，优先级较低。就这样，我慢慢的破茧而出，终于，我发现我们没有动核心业务，一套微服务体系已经搭建起来了。可能有人会比较好奇，你这样分开，旧系统和新系统是同时存在的。外部用户会受到影响吗？其实这里有个小技巧。也就是说，我在拆除微服务之前建立了一个代理。该代理专用于路由外部用户请求。每次推出服务时，都会对这组代理进行小幅调整。这样一来，用户将无法感知其背后新旧系统并存的情况。不过，话虽如此，我也想说这个方法真的很粗糙，我选择这个方法是因为实在是没有别的办法了。后来再做微服务的时候，吸取了很多教训。大方向还是需要优先明确业务模块的划分，然后基于业务模块的划分来创建微服务。总的来说，我对微服务架构的设计，后期需要分为两个时期。在这两个时期，我采用了不同的方法。我分开说吧。3.本土炼钢的传统业务分工第一次被迫从事微服务后，开始了自己对微服务架构的研究。我知道很多技术细节，以及如何划分业务，我承认我当时有点疏忽。所以，后来有新项目的时候，我在搞微服务的时候，就采用传统的业务划分方式来开发微服务。步骤如下：第一步：划分功能模块其实把功能模块划分清楚就可以了。如果是从零开始的系统，业务并不复杂，模块也容易划分清楚。如果是已有的大项目，那就要看系统的源码，根据源码和业务文档搞清楚整体的业务模块。第二步：整理功能模块的方法。仅仅搞清楚业务模块是不够的。您还需要将它们划分为单独的服务。因此，还必须确定服务之间的连接。这时候如果从头做起来容易，可以根据业务划分的情况直接创建相应的方法。如果针对已有的项目拆分，就很难做到了。需要仔细梳理源码，然后根据源码的类和方法，将各个模块之间的方法调用一一清理。很麻烦。第三步：对方法进行分类将所有整理出来的方法进行分类，分为两类：功能模块直接对外用户使用的方法，以及功能模块之间需要调用的方法。第四步：模块映射服务、方法映射API方法整理归类后，这时候就要将功能模块映射成服务。这个过程是必不可少的。功能模块到服务的映射一开始往往很粗糙，即功能模块和服务之间的一对一映射。然而，根据我的经验，这种简单的映射几乎是不可能的。总是有各种着陆问题迫使你重新调整。好了，业务模块和服务一一对应的假设已经做了，我们也梳理了业务模块的方法调用。然后在这些方法调用和服务的API方法之间做一个一对一的映射。当然，这种方法也很粗糙，几乎总是会出现需要调整的问题。第五步：根据实际情况进行调整。最后，我们开始按照我们上面的假设进行微调，业务模块和服务之间的映射被迫调整，主要有以下几个原因：1.拆分后网络交互过多导致性能下降。当我们拆分服务的时候，最后把以往一些业务模块之间频繁的方法调用映射到服务上，变成了频繁的网络交互。我们当然不能允许如此频繁的网络调用。对于这种情况，有两种处理方式：1、将服务之间的交互改为批处理；2.根本不要拆服务。把服务改成批处理就好了。一旦决定不拆除它们，就会影响之前设计好的映射关系。2、同步调用还是有可能造成阻塞的时候。以前本地调用做成同步方法，其实是无害的。因为大家都在同一个进程中，处理事件可以忽略不计。但是，现在家庭已经分开了，变成了服务之间的网络调用，那是会发生的。网络同步调用必须考虑容错和阻塞。所以，对于同步调用，必须从两个方面来处理：1、设置超时时间；2.使其异步。如果把一些同步方法变成异步方法，那么服务API和之前方法的映射关系可能要调整一下。例如，一个方法必须对应两个异步API：一个用于访问，一个用于获取响应。3.划分服务后可能需要重新考虑原有数据的一致性。最难做到的就是数据一致性，而数据一致性往往是无法避免的。所以微服务系统中就会有一套模式来解决这个问题。让我们在以后的文章中讨论它。4.事实证明，一些核心业务类可能与大部分业务密切相关。一套复杂的业务系统必然有一些核心业务。在代码实现中，往往是一个业务类，有很多字段。比如电商系统中的订单，就是一个非常核心的业务类别。它将用于许多业务。对于这种班级，他们有一个专业的名词叫神级班。因为大神类本身挂接了太多的业务，只有在划分服务的时候你才会意识到。.神类字段太多，很多业务都需要。因此，它确实阻碍了很多业务的拆分。这个时候还没有完全掌握领域驱动设计的本质，所以也没办法。这个时候我只能把这些神类分别拿来做成一个微服务。但这真的很难看。首先，这纯粹是一个粗制滥造的微服务，根本没有任何业务可言。其次，既然没有业务，就没有方向，没有限制。谁想添加访问数据的API，可以随意添加。最后这些神类对应的微服务会被很多微服务模块访问，压力很大，还得为此搭建一些集群，得不偿失。4.一个领域驱动的工具，用另一种思维方式解决问题其实一路走来，我使用传统业务划分的问题并没有遇到太多。对我打击很大的是God类，我一直在努力寻找修复它的方法。当我读到领域驱动设计时，我明白了这个东西只是需要改变。领域驱动设计其实没什么特别的，只是引入了子领域和限界上下文的概念。这两个概念对我拆分微服务最有帮助。分域本身其实是过去的一种传统工艺，只是拆分了业务模块。但是，它也引入了一个概念——不同子域之间的同名术语可能不是一回事。这就是我如何解决上帝类分裂的需要。如何解决？它是用“限界上下文”的概念来实现的。子域和限界上下文听起来很牛逼，但它们实际上是传统的业务模块和业务模块对应的服务。只不过boundedcontext明确的指出了service包含了实现的代码，他们统称为boundedcontext。在领域驱动设计思想中，各个子领域之间同名的技术术语实际上可能是不同的。而这个对应的实现，就是将原来的神类拆分成不同的子域中的不同类，每个子域中的类都包含了之前神类中的一些字段。例如，原来电子商务系统中的订单类，之前可能已经包含了用户、订购的商品、用户地址、金额等。但是在对应支付边界上下文的支付子域中，还有一个订单类，只需要两个字段：user和amount。在物流子域中，对应物流有界上下文，还有一个订单类，可能只需要两个字段：商品和用户地址。因此，通过这个思路，解决了上帝类阻碍微服务拆分的问题。但是，执行中还有一个问题没有解决。因为我们是为用户做的系统，所以用户看到的显示信息可能还是对应着原来神类包含的所有字段信息。比如在电商系统中，对于用户来说，订单信息中包含了很多其他的信息：商品、金额（支付子域）、用户地址（物流子域）……这时候，微服务其实已经有了自己的API网关，需要通过微服务网关将各个微服务的数据聚合成用户看到的顺序。同时，通过API网关，将用户看到的订单转化为各个微服务之间需要的订单信息，在各个微服务之间不断流转。而这是另一种模式，在以后的文章中会详细讨论。5、问题还很多。在这篇文章中，我谈谈我自己对如何拆分微服务的经验。然而，微服务并没有想象中的那么完美，它实际上会导致很多新的问题需要解决。在下一篇文章中，我会讲到划分服务后出现的一些问题。下篇文章见。本文转载自微信公众号“四猪外”，可通过以下二维码关注。转载本文请联系思源外公众号。
