微服务行业最佳实践

  

微服务架构如火如荼的发展了几年后，在行业内已经被很多公司和团队采用，微服务这块儿看似美丽的蛋糕，，让有的团队败走江湖，死的无比难看；也让有的团队顺利完成转型，积累了很多的行业最佳实践。很多最佳实践的最后都成为了一个个的名词，如玻璃碎一般，折射着神秘的光，实际上，这些最佳实践，就是一块块拼图，拼接起来，就是微服务的一个完整的版图。

领域驱动设计

领域驱动设计以业务为中心，划分不同的领域，形成不同的限界上下文，不同的限界上下文实际上就是微服务该怎么划分的依据。

限界上下文的划分不是单纯的只有业务角度，技术实现限界上下文形成的例子比比皆是，例如高并发要求，数据的实时性的要求，第三方系统集成的需求，以及应对遗留系统等各个场景的要求。

限界上下文的合理划分保证了各个服务模块儿的高内聚，维持了各自上下文的领域模型一致性。

微服务设计的出发点之一是控制服务规模，各个不同的业务模块分而治之，力求降低业务复杂度。但是微服务设计风格本身带来的另外一些技术复杂度如果得不到合理的控制，很快就会吞噬掉分离业务复杂度的红利。所以，分离业务复杂度和技术复杂度就成为微服务的应有之义和目标。

由此，Devops应用而生。

Deveops

Deveops是开发和测试，运维的结合，力求做到开发，测试，运维的全链路自动化处理，以自动化来处理微服务划分以后带来的的运维和开发复杂度，提高开发和运维效率，由此，持续继承和持续交付的理念诞生。

要做到持续交付，其中有一个环节必不可少，就是自动化测试，没有测试，就无法保证的基本代码的质量，代码的质量都保证不了，何谈交付？所以，TDD就成了在这个环节的行业最佳实践。

TDD 和 敏捷

TDD 的全程是Test Driven Design ，并不是一个简简单单的先写测试，后写代码，这个层次实在太浅了，关键在于Design，TDD的目的是指导我们通过测试的角度来设计可以测试的代码和业务模型，让测试一开始就成为我们的安全防护网，防止我们的代码和模型的错误发展和坏味道。从测试驱动的角度看，那句：“没有测试的代码，就是遗留系统”，毫不夸张，确实，你连测试都没有，你怎么拍着胸脯跟别人保证，我的代码没问题呢？

TDD 的另一个重要作用是：指导重构。在敏捷软件开发，极限编程的风吹了十几年后，绝大多数团队和开发人员对敏捷的含义并没有很深刻的理解，瀑布式开发依旧大行其道，一纸文档依旧是很多团队不同开发阶段的标志性输出。敏捷的关键是什么？答案是两个词语：快速和反馈，只有在快速反馈的前提下，敏捷所提倡的节奏才能形成。之所以在这里提到敏捷，是因为TDD对重构的指导作用，让我想到另一个词：有效。有效的反馈才是敏捷的应有之义，这样，敏捷的实际含义，应该是：快速有效反馈。TDD的节奏是：红-绿-重构，这样的快速节奏，和敏捷不谋而合。

领域驱动视角下的业务架构模型

回到领域驱动设计，微服务的出发点是达到技术复杂度和业务复杂度的分离，领域驱动的视角下，我们得到了完全不同于传统MVC三层架构的代码模型，整洁架构和六边形结构瞬间让我们醒悟到业务逻辑在代码中的核心位置，而数据库，第三方服务等彻底成为了基础设施（或者是南北向网关），通过抽象接口来隔离他们，层与层之间的关系，形成正交，彼此独立演进，不会影响其他的层。这样看来，微服务真的只是领域驱动设计下的一种部署形式和设计风格的最后体现，而正是这种体现，让很多人在没有弄明白微服务就下手后苦苦挣扎于技术复杂度泥潭而不自知的原因。

垂直细分的领域职能团队

微服务考验的不仅仅对于架构的设计能力和对于业务的理解能力，更是对传统的团队协作模式提出了挑战。传统的团队协作模式下，开发，测试，运维，产品团队都相互隔离，你走你的阳光道，我过我的独木桥，唯一的关联，似乎就是输出的文档，然而，文档的准确度和实时性都和敏捷所倡导的快速有效反馈相悖。所以，迈入微服务时代后，端对端的开发垂直细分领域的跨职能特性团队成为了团队合作方面的最佳实践。康威定律告诉我们：任何组织在设计一套系统（广义概念上的系统）时，所交付的设计方案在结构上都与该组织的沟通结构保持一致，小的团队更能保证有效的沟通，保证更高的工作效率。

用户故事

程序员与产品之间的梗在谈论了很多年以后，至今也还是一个让人津津乐道的话题。好多时候，这两个群体之间的思维是不在一个频道上的，微服务的时代，产品的快速迭代，让这种冲突更为明显。于是，有人探索出了在这个问题上的最佳实践：用户故事。

用户故事的一般格式：

As a（作为）<角色>
I would like（我希望）<活动>
so that（以便于）<业务价值>

用户故事把用户放在了需求的中心，以用户的视角来描述需求，这样，统一视角的叙述下，把最关键的事情描述清楚，定义出了对业目标的验收标准。最关键的，每个用户故事都是一个独立的，完整的功能，不至于我们把所有的功能开发完之后，才能看到需求的全貌。

总结：

以领域驱动的视角去看待业务和设计项目模型，划分限界上下文，得到一个个微服务的边界；以Devops来自动化我们的开发流程，分离业务复杂度和技术复杂度，结合TDD的方式来引导我们写可测试和可维护的代码（也是可以测试的模型），落实敏捷开发的快速有效反馈；用端到端的的领域职能划分团队达到高效沟通；用用户故事的方式描述需求，减少理解差异。这些行业最佳实践的完整串联，贯穿了一个项目从设计到开发，测试，上线，运维，迭代的整个生命周期。

微服务不是简简单单的接口RPC调用，它表达的是一种业务之间的高度自治和独立进化；微服务只是一个服务的部署形式，它的内核是领域模型的设计和演化。只能看到微服务的技术层面，一直在这个层面徘徊，我们始终只是在微服务的大门口徘徊，疲于奔命的同时，感叹需求的变化。

所以，想方设法落实行业最佳实践，才是微服这条路的康庄大道。