微服务设计 - 代码重构的技术

欢迎转载， 请注明出处。分享快乐叻。本文长度3000，需要坚持5分钟。

部署和集成技术成熟，微服务成为炙手可热的项目管理方式。关联书籍层出不穷，Sam Newman的微服务设计是微服务出版物中的之一。
项目进行旧工程改造，重复Sam Newman的<微服务设计>大作，收获颇多。遂把<微服务设计>与工程旧改关联的内容整理出来。抛砖引玉希望能对您有所启示。

微服务设计

书内容概要

• 通俗化描述： 书中微服务和关联的概念技术以通俗化的语言娓娓道来，简单易懂。它技术理论书，但不属于生涩难懂的那一类。
• 大量的延伸化阅读：本书内容是如下内容的提炼：《领域驱动设计》、《扩展的艺术》、《持续阅读》、分布式系统理论CAP\负载均衡\如何缓存等，以及大量的开源系统。可参考阅读
• 结构问题：稍显遗憾的是：书结构脉络不是很清晰，新手阅读时要自己整理。

前言

对程序猿而言，项目改造意味代码解构和工程改造。城市旧改意味着房东飞黄腾达，走向人生巅峰，代码旧改哪？程序猿却是拆迁队，心理 千万只 可爱的羊驼 在奔腾外，生理上还有“生命危险”，不排除被拉出去“祭天”的可能性。可是为了诗和远方，还要继续呀！所以程序猿群体都具备挖坑掩埋自己的天赋。

本文不是介绍微服务特性、优劣，而是从书中获取服务改造思路和理念。取我们所需是目的，想了解全书的童鞋请降低下期待。

服务改造目标

• 目标
  不论是不堪重负的单体项目，还是弹性十足的微服务项目。服务改造目标：

• 对外保证功能兼容；

• 对内代码易于维护、研发提效，向996说byebye(这个奢望就当没有....)；

具体而言，改造服务是个拆解的代码工程。书中提到拆解工程满足的前提:如下图所示。保证功能隔离、自治性是可维护和代码内聚的关键因素，也是架构良性发展的要素。

技术异构性：指不同服务使用差异化的语言、技术实现，可满足了技术演进需要。即一个服务可用新技术替代，而不会引起大量的修改。该方式不适合小公司：人员储备、流动、技术栈积累因素，会让后续出现不稳定因素。

• 拆解方法大比拼

当单体应用到达一定体量后，难以为继需要进行拆解。拆解方法很多，微服务是之一，但不是唯一。因地制宜才是良方。

SOA的设计方法曾经流行，它包含多个服务，服务间配合完成一系列供，它们之间的通讯以网络，而非进程调用的方式。目前而言如果单体应用需要拆解，是进行微服务化，而不是基于SOA的方式进行设计拆解。

下图拆解方法中，共享库是小的单体应用拆解好方法，即没有繁琐服务间依赖，也减少代码结构的复杂性。对Java工程而言，独立功能代码变为独立jar包依赖，不失为好的方式。

模块化拆解：对大的单体应用不适用。模块化是项目的开始选择。当需要改造时，在走模块化道路，意味着在阎王路上快马加鞭。

服务拆解.png

arkdown\服务拆解.png)

漫谈架构师

Sam大神给出了心中架构师的模版，如下图。我们关注其中一部分。

• 架构师服务边界：架构师工作涉及不同团队和服务的组织，那么他如何维护服务开发和运行哪？对服务内部主张自主决定，有条件选择技术栈、组件等。但为消费方提供标准化的服务。举个例子：项目服务间是REST信息传递，你提供MQ的机制，就不是标准的东西。
• 架构师如何做？他不是个PPT写手，而是要做个代码架构师，了解代码框架和实现，知悉、指定开发人员的规则。
• **代码治理： **代码管理常治常新，就如同重构一样是长期、不间断的过程。代码冗余、腐化更多的源于治理不利。方法：使用简明的范例、制定规范模版、集中管理等。
• 权衡技术债：这条很丰满，现实总打脸。
  架构师.png

建模微服务

我们总在谈微服务，那么微服务应该是什么样子哪？微服务概念描述了两个特征：高内聚、低耦合。可见，我们以此来衡量微服务，以及是否合理。

建模微服务.PNG

如何构建微服务，即构建微服务的原则是什么哪？Sam大神从Eric Evans《领域驱动设计》中获取灵感：限界上下文是构建微服务的原则。也就是说：理解单体应用的限界，就可对其进行微服务化。

• 限界上下文： 理清了服务间的界限。推荐读Eric Evans大作《领域驱动设计》。
• 建模方法：包含设计高内聚、低耦合服务方法和建议
  • 共享隐藏模型：它是隔离层，服务/工程间通过隐藏模型的接口调用，服务内部实现外部无法感知。
  • 模块化：上文提到服务间不建议使用模块化，但服务内可使用模块化，为后面的工程拆解做准备。一入模块深似海。
  • 建议：新项目不适合进行微服务化，微服务化时候已有项目。迭代限界划分，避免一蹴而就。

微服务集成

微服务集成是本书的重点章节，我们根据工程改造的需要，进行重点的描述。本章节分成：集成技术、集成方法、集成原则、版本管理来说明。

• 集成技术

集成技术图.PNG

上图集成技术指不同服务间如何进行通信的技术。书中详细描述各种技术的特点，微服务化时值得重点关注。从方法论角度我们不赘述。

• 集成原则

  下图是集成原则笔记，也是重构服务参考的标准。

  避免破坏性原文描述：

  某个服务做的修改，会导致该服务的消费方也随之改变。....我们希望选用的技术可以尽量避免这种情况发生。

集成原则.PNG

• 集成方法分析

集成方法基本方法如下图：

集成方法分析.PNG

上图不是以微服务化集成方法的笔记，而是以工程拆解的角度记录。共享库：一些公共类库也称为共享库。共享库是提供公共功能组件，消费房感觉需要订制。如数据库提供CRUD功能，Scala的类型类Ordering类等。

使用共享库/组件时，需要关注同步操作的风险。

• 版本管理

  下图服务改造和微服务化如何进行版本管理，以及需要面对的问题。

  
  版本管理.PNG

从版本管理策略看工程改造：

• 减少破坏性修改：有点像奥卡姆剃刀原则，能不修改就推迟修改。
• 多版本/不同接口共享：为减少质量压力，多版本/接口并存是合理选择。

其实，版本管理策略，在理想和现实之间需要兼顾。理论只能指导，而不是真理。

分解单体应用

单体应用分解原因丰富多彩。归根结底还是无法满足需求场景。下图是分解单体应用时，涉及工作：

分解单体系统.PNG

• 分解原则：书中包含多种原则。但我认为最主要的原则是：与技术无关，即按照团队结构进行分解。否则，系统腐化只是时间问题。

• 分解质量：方法是软件开发通用方法，作者一再强调表明：质量是一切工作的生命线。

• 分解方法：量化了限界上下文的方式：按照包进行拆解。由道到术。

测试

在质量面前，任何重视测试行为都不为过。

下图关于测试，Sam大神用极大篇幅讲述，可见其重要性和复杂性。

• 测试分类演变：从测试的金字塔模型逐步演化测试结构。
• 如何权限各类测试的优缺点。
• 每一类测试如何实现。甚至服务测试的技术如何选择？
• 提速增效的方式：如何解决测试缓慢问题？采用金丝雀发布,多版本共存运行等等方式。
  测试.PNG

从笔记的长度也看得出测试的地位。虽然它是微服务化的测试思想，在单体应用上，提速测试、测试分类等都是通用的思路。

微服务化原则

这一章节是全书的总结篇：(真想管中窥豹的话，最后一章就是那个点。)

虽然每个微服务本身很小，但它对架构的影响却很大很广，所以还是需要学习很多东西。本章，我会尝试总结一些贯穿全书的关键点。

微服务化原则.PNG

上图中，服务的高度可观察性指的是微服务化每一个服务都要可视化。书中讲述了可视化方法。不在我们工程拆解关注点，没有在文中描述。

总结

这是本要常读的大书，每次的收获都不同。本文采集部分论点、没有深入进行描述。感兴趣的大侠、巨侠们先看本文的图，有针对性阅读就好了。

未来很长，感谢各位看官的赞！！！