欢迎转载, 请注明出处。分享快乐叻。本文长度3000,需要坚持5分钟。
部署和集成技术成熟,微服务成为炙手可热的项目管理方式。关联书籍层出不穷,Sam Newman的微服务设计是微服务出版物中的之一。
项目进行旧工程改造,重复Sam Newman的<微服务设计>大作,收获颇多。遂把<微服务设计>与工程旧改关联的内容整理出来。抛砖引玉希望能对您有所启示。
书内容概要
- 通俗化描述: 书中微服务和关联的概念技术以通俗化的语言娓娓道来,简单易懂。它技术理论书,但不属于生涩难懂的那一类。
- 大量的延伸化阅读:本书内容是如下内容的提炼:《领域驱动设计》、《扩展的艺术》、《持续阅读》、分布式系统理论CAP\负载均衡\如何缓存等,以及大量的开源系统。可参考阅读
- 结构问题:稍显遗憾的是:书结构脉络不是很清晰,新手阅读时要自己整理。
前言
对程序猿而言,项目改造意味代码解构和工程改造。城市旧改意味着房东飞黄腾达,走向人生巅峰,代码旧改哪?程序猿却是拆迁队,心理 千万只 可爱的羊驼 在奔腾外,生理上还有“生命危险”,不排除被拉出去“祭天”的可能性。可是为了诗和远方,还要继续呀!所以程序猿群体都具备挖坑掩埋自己的天赋。
本文不是介绍微服务特性、优劣,而是从书中获取服务改造思路和理念。取我们所需是目的,想了解全书的童鞋请降低下期待。
服务改造目标
目标
不论是不堪重负的单体项目,还是弹性十足的微服务项目。服务改造目标:对外保证功能兼容;
对内代码易于维护、研发提效,向996说byebye(这个奢望就当没有....);
具体而言,改造服务是个拆解的代码工程。书中提到拆解工程满足的前提:如下图所示。保证功能隔离、自治性是可维护和代码内聚的关键因素,也是架构良性发展的要素。
技术异构性:指不同服务使用差异化的语言、技术实现,可满足了技术演进需要。即一个服务可用新技术替代,而不会引起大量的修改。该方式不适合小公司:人员储备、流动、技术栈积累因素,会让后续出现不稳定因素。
- 拆解方法大比拼
当单体应用到达一定体量后,难以为继需要进行拆解。拆解方法很多,微服务是之一,但不是唯一。因地制宜才是良方。
SOA的设计方法曾经流行,它包含多个服务,服务间配合完成一系列供,它们之间的通讯以网络,而非进程调用的方式。目前而言如果单体应用需要拆解,是进行微服务化,而不是基于SOA的方式进行设计拆解。
下图拆解方法中,共享库是小的单体应用拆解好方法,即没有繁琐服务间依赖,也减少代码结构的复杂性。对Java工程而言,独立功能代码变为独立jar包依赖,不失为好的方式。
模块化拆解:对大的单体应用不适用。模块化是项目的开始选择。当需要改造时,在走模块化道路,意味着在阎王路上快马加鞭。
arkdown\服务拆解.png)
漫谈架构师
Sam大神给出了心中架构师的模版,如下图。我们关注其中一部分。
- 架构师服务边界:架构师工作涉及不同团队和服务的组织,那么他如何维护服务开发和运行哪?对服务内部主张自主决定,有条件选择技术栈、组件等。但为消费方提供标准化的服务。举个例子:项目服务间是REST信息传递,你提供MQ的机制,就不是标准的东西。
- 架构师如何做?他不是个PPT写手,而是要做个代码架构师,了解代码框架和实现,知悉、指定开发人员的规则。
- **代码治理: **代码管理常治常新,就如同重构一样是长期、不间断的过程。代码冗余、腐化更多的源于治理不利。方法:使用简明的范例、制定规范模版、集中管理等。
-
权衡技术债:这条很丰满,现实总打脸。
建模微服务
我们总在谈微服务,那么微服务应该是什么样子哪?微服务概念描述了两个特征:高内聚、低耦合。可见,我们以此来衡量微服务,以及是否合理。
如何构建微服务,即构建微服务的原则是什么哪?Sam大神从Eric Evans《领域驱动设计》中获取灵感:限界上下文是构建
微服务的原则。也就是说:理解单体应用的限界,就可对其进行微服务化。
- 限界上下文: 理清了服务间的界限。推荐读Eric Evans大作《领域驱动设计》。
-
建模方法:包含设计高内聚、低耦合服务方法和建议
- 共享隐藏模型:它是隔离层,服务/工程间通过隐藏模型的接口调用,服务内部实现外部无法感知。
- 模块化:上文提到服务间不建议使用模块化,但服务内可使用模块化,为后面的工程拆解做准备。
一入模块深似海
。 - 建议:新项目不适合进行微服务化,微服务化时候已有项目。迭代限界划分,避免
一蹴而就
。
微服务集成
微服务集成是本书的重点章节,我们根据工程改造的需要,进行重点的描述。本章节分成:集成技术、集成方法、集成原则、版本管理来说明。
- 集成技术
上图集成技术指不同服务间如何进行通信的技术。书中详细描述各种技术的特点,微服务化时值得重点关注。从方法论角度我们不赘述。
-
集成原则
下图是集成原则笔记,也是重构服务参考的标准。
避免破坏性原文描述:
某个服务做的修改,会导致该服务的消费方也随之改变。....我们希望选用的技术可以尽量避免这种情况发生。
- 集成方法分析
集成方法基本方法如下图:
上图不是以微服务化集成方法的笔记,而是以工程拆解的角度记录。共享库:一些公共类库也称为共享库。共享库是提供公共功能组件,消费房感觉需要订制。如数据库提供CRUD功能,Scala
的类型类Ordering
类等。
使用共享库/组件时,需要关注同步操作的风险
。
-
版本管理
下图服务改造和微服务化如何进行版本管理,以及需要面对的问题。
从版本管理策略看工程改造:
- 减少破坏性修改:有点像
奥卡姆剃刀
原则,能不修改就推迟修改。 - 多版本/不同接口共享:为减少质量压力,多版本/接口并存是合理选择。
其实,版本管理策略,在理想和现实之间需要兼顾。理论只能指导,而不是真理。
分解单体应用
单体应用分解原因丰富多彩
。归根结底还是无法满足需求场景。下图是分解单体应用时,涉及工作:
分解原则:书中包含多种原则。但我认为最主要的原则是:与技术无关,即按照团队结构进行分解。否则,系统腐化只是时间问题。
分解质量:方法是软件开发通用方法,作者一再强调表明:质量是一切工作的生命线。
分解方法:量化了
限界上下文
的方式:按照包进行拆解。由道
到术
。
测试
在质量面前,任何重视测试行为都不为过。
下图关于测试,Sam大神用极大篇幅讲述,可见其重要性和复杂性。
-
测试分类演变:从测试的
金字塔模型
逐步演化测试结构。 - 如何权限各类测试的优缺点。
- 每一类测试如何实现。甚至服务测试的技术如何选择?
-
提速增效的方式:如何解决测试缓慢问题?采用
金丝雀发布
,多版本共存运行等等方式。
从笔记的长度也看得出测试的地位。虽然它是微服务化的测试思想,在单体应用上,提速测试、测试分类等都是通用的思路。
微服务化原则
这一章节是全书的总结篇:(真想管中窥豹的话,最后一章就是那个点。)
虽然每个微服务本身很小,但它对架构的影响却很大很广,所以还是需要学习很多东西。本章,我会尝试总结一些贯穿全书的关键点。
上图中,服务的高度可观察性
指的是微服务化每一个服务都要可视化。书中讲述了可视化方法。不在我们工程拆解关注点,没有在文中描述。
总结
这是本要常读的大书,每次的收获都不同。本文采集部分论点、没有深入进行描述。感兴趣的大侠、巨侠们先看本文的图,有针对性阅读就好了。