【图灵学院】如何使用微服务让你体验前所未有意味的秘密

使用微服务意味着什么呢?

首先粒度的问题是至关重要的,当你在思考微服务的边界问题时,这应该是使用微服务架构需要做出的一个最重要的决定。在这个过程中需要平衡好内聚和耦合的关系,一方面为了加强内聚你可能需要将某一些服务合并到一起,另外一方面为了解耦,需要对某些服务进行拆分。事实上在使用微服务架构的整个过程中都充斥着来回往复的拆分和合并,直到你真的理解了服务的边界应该是什么为止。我们后面会继续回到这个问题上。

微服务中的各个服务个体是可以独立扩展的,也就是说如果某个服务上的需求量猛增,我们只需要扩展该服务即可,于其他服务无关。相应的,对于各个服务的状态监控也非常重要。如果你手头是一个单块,从定义来看,理论上你需要监控的只有一个东西。而到了微服务里面,因为我们有大量的小型服务,因此需要对所有这些服务进行监控才行,你需要清除的知道每一个服务是不是在工作,是不是在正常工作,为此光监控就会需要更多的机器。

在微服务中,我们还需要考虑服务挂掉的情况,而这些情况在传统单块架构里面一般不用怎么考虑。比如我们有一块业务需要依赖数个独立的微服务,那么我们需要考虑的失败场景就相当多了,基本上是把所有这些可能的失败进行排列组合,而不得不说的一点是,在传统单块架构里面这些可能根本就不成之为一个问题。

在微服务架构中,因为我们有很多独立的单元,它们需要独自进行部署,因此我们真心离不开基础设施的自动构建,自动化部署和持续交付这些基础。在微服务中,虽然我们讲在不同的服务中可以使用不同的技术栈,但是这种灵活性如果任其发展最终也会完全不可控,因此我们需要管理好这种灵活性。我之前呆过的一个项目里面,光是XML解析就有11种不同的方法,是的你没听错,11种之多。一般来讲我觉得两种XML解析器我尚能接受,但是11种实在是难以理解。因此在微服务架构中,我们必须要避免引入所有类型的编程语言,引入所有不同种类的数据库,没什么原因,明眼人都知道,我们不能这么做。在系统的技术栈方面,我们必须在某个层面进行控制,否则一发不可收拾了。

当然最终一致性也必须管理好。一旦我们开始将数据分散到各个不同的服务单元里面去,我们必须考虑到这对于信息传播会有什么影响。其中的一个结果就是,我们需要给业务人员讲清楚,什么是最终一致性。一般而言我觉得业务人员会理解成“可能会一致”,而不是最终会达到一致。我们必须时刻想到由于最终一致性的存在所可能产生的各种后果。同样,如果我们用的是一个大而全的关系型数据库的话,压根就不会存在这个问题。

好了,大家看看我们列出来的这些个问题,他们一个比一个复杂,而在传统的单块模型中,这些问题我们根本不用想。当我们回顾这些问题的时候,不由得会想到我们的初衷,如果我们的初衷能够得以实现,最少能弥补解决这些问题时所带来的痛处。我们的初衷是什么呢?让系统能尽可能快的响应变化!另外一个方面,这些问题也在一定程度上警醒着你,微服务这个东西不是你想象的那么简单,不是照着教程做一遍就可以大功告成,然后出门跟人炫耀:哥在搞微服务哦,牛逼吧!

最后有一点差点忘了说了,接口的改动也必须有个限度。在定义清楚服务边界的时候,你少不了要修改一些接口协议,在修改的时候务必想清楚这个修改意味着什么。这个也深受团队成员结构的影响,比如如果写另外一个服务的人就在你旁边,改起来三两句话就搞定了,但是如果团队成员咫尺天涯或者天各一方,这个沟通过程本身就是一个巨大的成本。

好了,以上这些就是我认为的在准备使用微服务的时候,需要想清楚的一些问题。

好了,我们现在有两个选项。第一个是一片绿地,就好比我们拿到一个空白的项目,没有任何的遗留代码。这种情况也有,但是很少。另外还有一点,在马丁即将发表的一篇文章里提到,我们并不建议在一个崭新的项目中一开始就使用微服务进行开发。因为你很可能并不真的理解业务领域,从而也很难理解各个服务的边界。因此在这种项目中,可以先做成单块的,进行适当的模块化,加深理解之后再考虑演进成微服务。总而言之,你迟早会走到这个点,就是我们怎么将一个单块系统拆解成微服务架构的。

首先,想清楚边界上下文。这其实是从领域驱动设计一书中拿过来的概念。所谓的边界,指的是你可以将某些部分用一个圈圈起来,圈里的内容代表了一定的业务面。这个所谓的边界其实就是我们设计服务边界时的一个重要指示。再回到我之前说的那个问题,你需要对你的系统有一个全面透彻的认知之后,才能做出这些决定。作为划分服务边界的第一个提示便是:尝试按照领域驱动设计的方式来思考服务的边界应该在哪里。

其次还是这一点:从业务能力的角度来思考服务的边界。想想系统所提供的产品、服务是什么,从这个角度想想怎么样才算一个合理的服务边界。

想想调用者需要什么。与提供方驱动的方式不同的是,你需要想想这个服务的使用者会需要些什么信息。也就是说需要从真实的需求开始想问题,而不是一些作为提供方揣测出来的需求。

想想服务之间的通信模式。想想哪些服务,哪些系统可能会用到同一组数据,不同的服务之间怎么合作来实现一个特殊的业务产出。特别是当我们在犹豫是要将两个服务分开还是合并到一块的时候,想想拆开之后可能产生的各种通信,以及通信失败的情形等等。

想想数据结构。一般而言,大家不愿意花太多精力想怎么保护数据的问题,也不会纠结太多最终一致性产生的影响。你怎么设计数据,合适的数据结构应该是什么样的也可以作为一个指示你如何设计服务边界的提示。因为服务是持有数据的。我们不再想的是一个数据库周围围绕着一堆服务,而是每一个服务有一个自己的持久化存储。

想想联动变化模式。比如有两个业务部分需要一起改,其实某种程度上在提示你,是不是把这两块放到一个服务里面更加合适。因此多想想未来可能产生的各种改动,对你做出决定也会有所帮助。

做好出错的准备,你可能经常需要将一些服务进行合并,而后搞不好又要重新再拆开。由于服务还牵扯到数据,如果两个服务的关系是一个服务主要负责一部分数据,而另外一个服务中对这部分数据只是进行缓存的话,你或许还要考虑一些需要数据迁移的情况。一般而言你不会想经常修改服务的边界,因为这会带来一系列的应用程序,数据的改动。但是还是那句话,做最坏的打算。

最后的一点是:做一名有耐心的读者。这其实扯到演进架构的内容了。首先是我们不能把build搞挂了。我们能做的是只有在没有别的选择的时候,我们才开始改。而做耐心的读者就是为了确保他们改的确实是你所需要的。也就是说在正式确定修改我们实现之前,需求本身可能改的还要多一些。

OK,那么微服务与演进式架构还有什么联系呢?其实当我们谈论演进式架构的时候,其实是有很多不同的原则的。这些原则都很严格,而微服务某种程度上展现出了一些演进式架构的原则。我们在谈微服务的时候,主要是想用它来快速应对频繁的需求变更,因此微服务所承载的期望便是让我们能尽可能快的适应变化。而演进式架构中所倡导的进化性与此不谋而合。可进化型并不同于可维护性,但也不是说要怎么预测未来,而是一种随时准备响应变化的状态,而不管你是否提前就设想好了这些变化。以前关于可进化性的一个理解误区是,我要非常聪明的想到所有可能出现的变化,并且为所有的这些可能的变化写好代码,哪怕到头来根本就没变。因此微服务将可进化性作为其首要目标。

耐心的读者,是的前面已经提到过一遍了。我们可以做出任何改变,但这种改变必须是我们经过大量的沟通讨论之后得出的统一结论。

遵从康威法则。我们需要关注怎么组织团队结构,以及不同的团队结构可能影响到最终的系统形态。只有团队对服务有很好的所有权意识,团队做出来的微服务才是这种松耦合的独立服务。某些采用了微服务的组织中,但是并没有一个专门的支持维护团队,因此每个团队成员会不自觉地将他的那部分代码写好,因为谁也不想大周末的还要跑到公司来修BUG。

适当耦合。我们在谈演进式架构的时候,其实总是在平衡耦合与性能、复杂度等其他因素之间的关系。

协议。在微服务架构中,各个服务可以独立演进。那么必不可少的一环就是相互之间的接口协议。通常而言我们可以借助于一些协议测试工具或者文档来确保相互之间正常工作。作为服务提供方同时还应该提供对应的接口测试给调用方,而一旦调用方发现这个测试失败了,马上需要找到提供方确认问题。测试的另外一重含义是,只要这个全面的接口测试是正常通过的,那么无论提供方把代码改成什么样了,调用一方都不用关心,因为大家都是独立的,链接这彼此的就是这些接口协议,这也是为什么微服务中的接口协议显得如此重要的一个重要原因。

最后,作为一名来自ThoughtWorks的员工,我不得不谈谈测试相关的事情。我们发现如果你始终沿着方面测试的方向设计架构,最后的架构会更加简洁。而且易于测试的系统一定是有一个清楚的定义的,你甚至不需要颗粒度太细的测试,哪怕只有一个非常顶层的端到端测试,但是只要这个测试能简单明了的描述了其行为就已足够。当你的架构设计的很好,边界划分的很清楚的时候,系统本身就应该是很好测试的。我们发现,一般而言,不管是从代码层面还是系统层面,关注测试始终会让你的架构更加完善。而且一般而言,基于测试定义的边界,也让整个架构更容易做出改变。

微服务有些什么特点呢?

第一个显而易见的特点是,微服务中每个个体服务单元很小。这里所谓的小其实并不是绝对的,其思想的要点是,与其搞一个大而全的服务体,我们更倾向于小一些的单一服务。微服务的另外一个特点是,这些服务是按照业务能力构建的。之前我们经常掉入一个陷阱,就是从系统的角度思考问题,而不是从业务角度。现在我们不仅要思考系统能力,更要思考业务能力。并且我们需要按照业务能力来组织工作。对于业务部门而言,如何实现的并不重要,他们所关心的是系统长什么样子,怎么样能方便用户使用。业务部门是这么思考的,我们也对应的需要围绕业务能力进行设计。

微服务中的服务个体都是可以单独部署的。也就是说,只要没有动接口协议,在修改某一个服务个体的时候,完全不用理会其他服务个体。在微服务中,只有很少一部分的集中管理,而由于各个服务个体之间是相对独立的,因此我们甚至可以在不同的服务单元采用不同的技术栈。比如某一部分的计算逻辑比较复杂,我们选用clojure,另外一部分则对应着很强的对象模型,我们可以用一些面向对象的编程语言等等。

在微服务中,我们主张“智能端点”和“傻瓜管道”。基本上如果管道两边都按照一定的假设强制执行的话,需要重新配置时就会简单许多,而并不需要时刻监控管道中的各种中间状态。当我们尝试把现在的这种模块拆分的时候,需要考虑的另一个问题是,数据库的结构应该是什么样的?具体的问题还包括数据如何进行维护,其他单元如何缓存等等。毫无疑问在微服务中,数据结构的形态会有很大不同。

Java架构师教程免费试听地址:https://vip.tulingxueyuan.cn/page/1690373