基于微服务架构的技术实践（附PPT）

Posted 2021-04-14 EAWorld

大家好，今天分享的是“基于微服务架构的技术实践”，标题有点土，希望内容对大家有用。这个是我上周在CSDN北京沙龙上分享的内容的改版，加入了一些设计部分，才见了一些理念部分和自身平台的具体内容，篇幅稍长，我们尽快进入主题。

内容分了三节，重点是第二部分，包括架构选型参考、6个关键模块设计、以及通用的概念模型、部署模型图等。

· · ·

对微服务的认识

先进入第一部分：包括两块内容，说说历史，说说问题。

微服务的说法由来已久，但真真风靡起来是2012年martin flower提出的，但为什么现在大家一谈微服务就容易吵吵呢，因为martin flower给了给多参考原则，但并没有给出最佳实践，是的现在大家一讨论就会说应该按什么什么拆分，应该怎么考虑交互与安全等等。

不妨我们先从企业应用架构来看看，微服务与原来有什么区别：

第一个就不说了，第二个垂直架构，典型的比如SSH框架，帮大家考虑了模块化、MVC等，但并没有考虑服务化。第三个是分布式架构，以SOA为代表的这类技术已经热了很多年，现在也是企业架构的主体支撑部分。而第四个以微服务架构为支撑的技术虽然在一些先进企业或互联网公司已经运用，但从生态上来看，还有很长一段时间要走。

所以会有了下面的这些争吵：

曾经被人问的最多的就是，微服务应该按什么拆分，以前会和别人说DDD，说康威，现在更多是不想回答了，因为怎么说都有理，怎么说也都有实际难以解决的问题。

再比如，微服务让开发变得更简单，是完全无依据的。这个往往建立在你已经把微服务通信框架、管控框架、部署框架、分布式事务、开发规范等一系列都完全制定好后，再结合技术与业务分离等实践后才能给出答案，切勿认为微服务可解决开发问题。

· · ·

微服务架构实践

回到今天的主体第二部分：

包括了技术和架构参考，平台主要架构设计，以及关键的模块设计。

参考1：平台品质属性，这个图大家应该不陌生，是在说一个平台或者模块的设计，很难把各个维度面面俱到，往往是有取舍的支持，图中“+”代表可同时享用，而“-”代表会有冲    突，著名的CAP原理其实也是这个意思。

参考2：扩展立方体，这个是在说平台提升扩展性的几个维度，X轴是通过克隆的方式，Y轴是通过业务功能拆分的方式，Z轴是数据拆分的方式。这个在系统设计中是一个进阶参考，但在设计之初尽量要考虑清楚一定时间段里，采用哪种模式作为默认方式。

参考3：Heroku的12Factor，这个以前提过，这些因素为系统的CloudNative目标考虑，让云上云下得到同样的体验。

参考4：谷歌的优秀框架Borg，谷歌内部的管理调度核心，支撑着谷歌上万台机器及业务的运行，这个虽然是不开源的，但其设计思路和架构是很容易被找到和学习的。参考这个的原因是谷歌本身内部就是容器与微服务架构的生产运用，是一个真正大规模的实践参考。

基于上述的参考等，我们验证过上述的技术栈，用于支撑微服务架构，当然这里面已经有不少被我们放弃了，上图是从对象类型（横向）和功能要求（纵向）给技术做了一些罗列，也是我们平台使用的开源图谱，大家有兴趣可基于某几个来探讨。

紧接着我们开始尝试微服务支撑平台研发，因为前面的误区提到了，微服务其实对支撑（开发、部署、运维等）平台的要求比传统更高了，所以这个正是我们的市场定位之一。

· · ·

在做的过程中，我简单总结：有3个思考和6个关键设计，这里其实篇幅考虑，省略了很多，比如自动化测试、比如一体化监控、比如安全控制等，后面应该会有同事往一些聚焦的话题分享。

思考1：我们要一个兼容企业情况的模型，比如说：

有些企业会考虑生产上VM，开发测试上容器；

有些企业需要开发测试预发上线四套环境，有些只要两套：

有些企业环境间要求完全隔离，有些只要逻辑隔离；

有些企业要求对接下层资源池，有些则完全没有资源池的概念；

那概念模型上我们怎么办？上图是一个片段，核心是业务运行及namespace，我们认为下层无论资源有没有池化，都需要加一层Namespace的管理，这个管理有很多目标，比如隔离，再比如池化。

然后紧接着是pod，这个概念参考了kubernetes，在微服务运行时，一直强调一个业务的独立性，比如一个业务，其应用及数据库是绑定的，那我们认为这种就是一个pod（豌豆荚），体现的是一个独立业务（服务）。

再从pod往下（一个pod无论内部如何，一般是跑在一台宿主机的，业务内部尽量本地调用），pod可以包括多个进程，也可以包含多个容器，也就是上图的pod与process的关系

再接着pod要求是集群的，所以一个pod可以有多个副本，也就是上图的pod与replication的关系。

这张图其实是一个详细的对于概念模型实际运行的部署架构图，这里我就不展开讲了，有兴趣可以结合上一张图一起看。

思考2：设计原则现在人人都会提，但微服务架构里，我觉得最重要的几个原则是这些：

隔离失败：微服务架构下，相互间的通信越来越多，不像单块架构那样，要坏一起坏，如何不受别人影响，以及自己不破坏别人，是要考虑的重点。

宽进严出：男总老拿Unix的设计来批我，这个其实就是其中一项重要原则，运用到微服务上，每个微服务要足够宽容，让更多人，更多方法可以接入，但返回的结果一定要严谨，要对别人负责。

PDCA：微服务下要以服务为级别快速迭代，迭代的依据是什么，要能够收集的来自上下游的足够反馈。

MVP：毕竟前面提到了，微服务架构的最佳实践太少，不要试图一上来就做大而全的东西，一步一步走。

思考3：数据是最有效的依据，现在支撑微服务框架的开源技术很多，太多，用一个东西要有对比，要对比就要有测试数据，不是只有资料。

· · ·

接着我们谈谈关键的设计（这里列了6个）

关键1：屏蔽异构环境，尤其像我们这种公有云和私有云同时发展的，要考虑各类环境（VM、容器、KVM、XEN、EXSI、NAS、SAN、CEPH、GlusterFS、SDN），这个也没什么特别的好办法，就是看经验，能力积累，架构一致。

同样是关键2里的：隔离，隔离有逻辑有物理，大家可结合实际需要来选择，从宿主机隔离，到Namespace隔离，到建立逻辑子网，以及内部的iptables策略配置等。

关键3：微服务伸缩与漂移，上图里万年不变的公式。以漂移为例子，漂移有很多触发可能，有因为故障的，有基于优化考虑的，像优化这种，就要求定义很多维度，结合对微服务的监控打分加权。

同样是关键3，要求的两个基础能力，第一是对于微服务点线面结合的监控，第二是监控数据的存储分析（微服务散落各地，要汇总合并，要能串接分析）

关键4：微服务的升级与回退，既然要求快速迭代，那平台设计上需要考虑：

发布要原子化，可编排。

标签设计，让每个动作、每个状态、每个资源都可以标识。

状态设计，部署是原子化的操作，而内部的状态设计同样重要，可结合状态做挂起、唤醒等诸多操作。

版本规范，这个无论是微服务还是传统的都很重要。

路由能力，微服务这种快速迭代发布，伴随试错试对，快速变更，灰度等，对流量的出入动态性要求很高。

同样是关键4，这个其实是个有动态效果的图，这没贴上来有点怪，就不赘述了。

关键5：前面的原则里大家是否还记得提到了隔离失败，就是这个东西来做的，股市要熔断，微服务同样要，而熔断器的设计参考了标准的三态设计，默认关闭，调用出错率到一定程度半开，半开时，允许一部分流量继续，如果一定时间还是出错（这个时间结合MTTR），就全开；

同时还有一个关键，就是上下游调用时，拿上游来说，对于不同微服务的调用，本身要采用不同线程池，防止影响。

关键6：微服务注册于发现，和上期的APIGateway不一样，这个更多是微服务之间的，通过服务的注册，支撑最终的客户端和服务端集群模式，客户端集群类似Dubbo，服务端类似传统Ngnix；不同于dubbo或motan，注册中心我们用etcd实现。

· · ·

总结与展望

接着就是第三部分了：我们现在已经在客户那边做一些私有云下的微服务架构实施，同时对今天的分享做个总结。

跑出去实施才发现，你认为的往往真不是你认为的，客户传统服务也希望拥有微服务的管理能力（比如持续发布、熔断与升级），那需要怎么做；客户的很多小工具都希望在新架构中同样发挥作用，比如像脚本管理这种，那怎么与平台结合。这个一言难尽，建议安排的同学是不是后面我们可以安排分享一些客户案例。

我们在微服务支撑平台的实践过程中，有些经验各位可参考：

尤其最后一条，前些天从饿了吗的架构师那边学习，发现跟开源这件事情，真的是个持续过程，用开源不是简单的使用开源，而是如何cover开源。

总结下，今天分享（时间关系做了一部分片子的裁剪），从架构演进及认知误区开始，讲了我们的参考架构，我们的微服务支撑平台的概念模型和关键设计，最后做了简单的实施问题描述和平台时间总结。

现任普元信息主任架构师。长期致力于IT技术研究、产品设计与开发、架构咨询等工作，擅长Web、OSGI、CI/CD、服务治理、云计算等领域技术。对DevOps、自动化运维、微服务架构有着浓厚的兴趣。

关于EAII

EAII（Enterprise Architecture Innovation Institute）企业架构创新研究院，致力于软件架构创新与实践，加速企业数字化转型。

eaworld是EAII的官方微信账号。

阅读原文，下载课件 ↓↓↓