关于微服务:微服务与-DevOps实践技术架构与组织架构-IDCF

一、概述

首先，咱们来看看微服务的定义：微服务是一个界线明确、高度封装、松耦合、能够独立部署和独立扩大的服务利用组件。如图所示。微服务架构基于 SOA 和畛域驱动设计（DDD）构建，其次要目标蕴含以下三个方面：开发的敏捷性、部署的便利性及明确的可扩展性。

其次，微服务和传统的 SOA 有什么异同：

• 从设计原则上来讲，微服务架构遵循 SOA 的设计准则。
• 小的、可重用的服务并不一定是微服务，微服务架构强调麻利、独立开发、独立部署、独立扩大，重用在某种程度上会影响敏捷性。

微服务架构为了实现其麻利个性，在 SOA 架构束缚的根底之上又增加了新的束缚，微服务之间不能相互依赖，因而要求微服务可能独立部署、独立扩大，微服务之间的依赖越少越好。

微服务中的一个服务只实现一个独立的个性。

对于微服务而言，尽量不要为内部利用公布代码级 API，能够通过服务调用或者事件解决依赖问题。

微服务中的服务之间最好通过异步事件交互。

微服务中的每个服务都领有本人独立的数据。

另外，微服务架构的长处有很多：

• 敏捷性：微服务不仅能够进步开发的敏捷性，还能够减速继续部署（CD），从而使开发团队可能尽快部署新的性能。
• 缩小危险：因为每个微服务都是比拟玲珑并且独立部署的，因而能够缩小每次部署的危险。
• 适宜分布式开发：微服务之间依赖水平低，因而能够更加灵便地独立开发。
• 技术灵活性：微服务之间的耦合水平低，因而技术团队能够依据不同的特点抉择最合适的技术栈，例如利用不同的编程语言解决不同的畛域问题。
• 可扩展性：一个利用有许多微服务组成，每个微服务能够依据须要独立扩大，而无须对整个利用做整体扩大。

鉴于以上长处，咱们来看一下微服务的实质。微服务在实质上是一种服务实现模式，微服务能够实现一个利用中独立的业务性能，而不是整个利用或者模块，因而，微服务其实是将单体利用的复杂性从程序外部转移到了服务组件之间，这就对微服务形象的粒度有一个比拟高的衡量要求。

对于微服务的粒度，大家探讨的最多，这也是实际过程中常常遇到的令人纠结的问题。实际上，如果形象粒度太细，就须要大量的服务编排来满足业务场景，而大量应用服务编排就可能会导致微服务退回到 SOA 模式（服务编排是相似 BPM 或者 ESB 的零碎）；而如果服务粒度太粗，则不利于开发的敏捷性和部署的便利性。

微服务的次要目标是实现麻利，微服务架构的次要构建形式是采纳畛域驱动设计，而畛域驱动设计次要包含如下五个概念：

• Bounded Context
• Context Map
• Event Sourcing
• CQRS
• BASE

微服务的粒度并没有一个明确的界线，也就是说“尺寸”是绝对的。通常，微服务的粒度和对敏捷性的要求密切相关，往往粒度越细其麻利度也越高，然而并不是所有的利用对麻利的要求都那么高，也就是说在微服务的设计和实现过程中，对于粒度的大小能够做适当的调整。对于想要采纳微服务架构的团队，首先要思考如下几个前提条件：

• 现有软件架构是否曾经服务化或者依照零碎性能做了模块化切分。
• 团队的麻利成熟度如何，是否有足够的 DevOps 教训。
• 开发团队是否有足够的架构设计能力来适应采纳微服务所带来的设计办法、模式以及技术架构上的微小差别。
• DBA 团队是否有能力和志愿制订新的数据管理模式——将数据管理的形式由原来的集中管理转变为去中心化治理。
• 运维团队是否有足够的能力为微服务提供全新的环境管理工具、部署工具和监控工具。

综上所述，咱们倡议微服务的演进线路如图所示。

• 从单体利用或者传统分层架构的利用向服务化过渡，通过封装和组合等形式提供对外公布接口的能力，从而晋升利用的可拜访性。
• 通过重构将 Domain-Level（畛域层面）的功能模块转变为能够独立部署的服务，从而晋升整个利用的敏捷性。咱们将这种可独立部署的服务称为 MiniService，其粒度比微服务粗，因此形象难度比拟低，然而也能在肯定水平上取得微服务所带来的敏捷性晋升的益处，然而对 DevOps 的基础设施等要求没有微服务高，因而倡议没有微服务教训的团队能够从 MiniService 开始尝试。
• 通过 Feature-Level（个性层面）的形象，依据繁多职责准则将 MiniService 拆分成微服务，从而取得更高的扩展性和敏捷性。

二、融数数据微服务的架构选型

咱们在构建微服务体系的过程中，经验了技术选型、技术验证、引入开源实现及齐全自研等一系列的过程，其中也走过不少弯路，当初回想起来，感触良多，在这里跟大家分享一下，心愿可能有所帮忙。对于技术选型，咱们不心愿反复创造轮子，也不心愿齐全受制于开源的实现，所以在技术选型时遵循如下准则：

考查社区热度、架构成熟度、学习曲线、可维护性，如图所示。

尽量关照现有服务的开发方式和框架的应用习惯，不对目前的研发团队造成太大的冲击。可能给程序员提供何种能力？咱们的冀望是：

• 不便开发
• 不便迁徙
• 多协定反对
• 多语言反对
• 不便监控
• 不便运维

咱们比拟了可能用到的一些开源服务框架，并对它们的性能点进行了评估，如图所示。

因为之前团队采纳 RESTEasy + Spring Boot 的形式实现服务，不心愿对现有的零碎和产品产生太大的影响，因而决定服务框架首先须要反对 REST 服务，又因为 Netflix 提供了比拟全面的解决方案，并且 Spring Cloud 在遵循 cloud-native 准则的根底上对 Netflix 进行了比拟敌对的封装，因而初步的论断是能够基于 Spring Cloud 进行二次开发，封装咱们本人的微服务框架。

通过半年的实际，咱们发现 Netflix 技术栈的思维不错，然而很多实现并不是特地完满，例如：

• Zuul 提供的 Edge Service 及 API 网关是齐全基于 HTTP 协定的过滤器实现的，基于 HTTP 协定的同步调用形式会带来性能的损失，并且不足长连贯的推送及多路复用的能力。
• Zuul 不能满足 RPC 调用的需要，而在大规模团队合作的过程中，契约优先的开发方式优于代码优先的开发方式，因而对于利用外部交互来讲，RPC 框架从治理和合作的角度要优于 REST 服务。

基于 Eureka 的服务注册仍然是中心化治理的形式，与传统基于 ZooKeeper 或者 etctd/consul 的治理形式一样，中心化的治理会给服务的部署带来十分大的妨碍，须要对不同的环境配置不同的核心注册服务器，服务的版本治理及服务注册信息的同步也会带来问题，更加蹩脚的是，在某些服务不失常的状况下，客户端须要进行大量的判断，防止出现治理风暴等问题。

因而，咱们起初果决转换思路，对之前的微服务框架进行了彻底的革新：

• 基于对 gRPC 的封装，构建 Service Provider 的全新实现，代替 REST 服务。
• 通过 Proxy 形式，实现 gRPC 与 REST 服务的互相转换，放弃零碎兼容性。
• 进行去中心化治理，通过 Proxy 来实现端点治理，将客户端治理变为服务端治理。
• 通过扩大并集成 Zipkin 实现服务链路监控和运行时拓扑收集。
• 构建 Endpoint inventory 服务，以 semantic versioning 的形式治理服务版本。
• 将 Proxy 作为服务部署的执行端点，通过 VIP 绑定，透明化客户端寻址工作。利用 Proxy 提供轻量级的负载平衡、流量管制及灰度公布的性能。

三、设计思维

融数数据微服务架构的整体设计思维如图所示。

该设计思维的具体阐明如下。

• 面向运维的设计，配合 DevOps 平台，提供服务生命周期治理及易于被监控的能力。
• 面向开发者，正当封装。开发者毋庸理解 gRPC 的具体实现。
• 基于 IDL 的契约优先的开发方式。
• 提供欠缺的测试框架和 Mock 工具。
• 提供欠缺的易于监控的能力。

四、总体架构

融数数据微服务总体架构（Graeae）如图所示。

4.1 总体架构的个性

融数数据微服务总体架构有如下个性。

• Graeae 架构与协定无关。该架构能够基于 Netty4、线程模型及 buffer pool 进行调整，以缩小 GC 压力并通过线程切换晋升性能协定。
• 遵循 protocol buffer 协定，能够做到通用性强、序列化性能好、压缩效率高。
• 语言中立，目前整个架构反对 Java、Python 和 Go 三种语言的开发。
• 引入了熔断器机制、流量管制、服务治理。
• 基于 Proxy 和 PaaS 平台进行分布式治理监控。
• 应用集成 Zipkin 的调用链监控，以及基于 Pinpoint 的 APM 监控。
• 对于该架构而言，间接调用的性能好于反射调用，且应用 Netty4 线程模型优化。

4.2 具体实现

服务提供者 Endpoint 基于责任链模式（如图所示）对 gRPC 进行封装，对屏蔽了 gRPC 框架的事件驱动采纳同步调用形式，不便业务迁徙。

Endpoint 封装了脚手架工具，提供基于 ProtoBuf 的 IDL 接口定义语言，应用契约优先的形式定义服务，并能够自动生产服务端和客户端的代码框架。

代码优先意味着实现简略，可能疾速执行。问题也很显著，可能和某个具体语言绑定，面对多语言环境，其买通老本较高。

契约优先的中立性提供了一个两头桥梁，让面向多语言成为了可能，基于契约的元信息为后续治理和演进提供了入口点。毛病是须要引入契约语言的学习，并与多语言进行适配。

Endpoint 采纳生命周期自治理的形式，提供容器化的生命周期治理 API 和相应的 SPI，不便扩大及与 DevOps 工具联合。

内部治理（如 Tomcat）让用户不必关注本身的起始、沦亡，但带来的有余是对生命周期的治理绝对削弱、部署的依赖治理扩散。

过程自治能够增强其对本身生命周期的治理，高内聚，不将依赖扩散。在肯定水平上可能带来部署的便当及不同部署环境的适应性（如云环境）。为优雅敞开提供切入点，进一步加强对系统的可控性。

从对环境适应性和对生命周期的治理能力思考，过程自治有着不可疏忽的劣势。

Endpoint 将配置与代码拆散，提供多种形式的配置笼罩能力，使得扭转配置毋庸重新部署。

配置和代码一起进行的长处是使开发变得简略，但有余也很显著，即面对不同的环境须要部署多套代码，复杂度减少。

配置和代码拆散后的长处是真正做到了只部署一套代码。配置信息按环境独立配置，不受环境制约，可随时调整。

集成 Spring Boot，提供自定义注解形式，可能疾速启动服务，不便开发。

// 服务提供方
public class SmsTemplateApplication {public static void main(String[] args) {new SpringApplicationBuilder().sources(SmsTemplateApplication.class)
.web(false).showBanner(false).run(args);
}
}
// 服务实现
public class SmsTempletServiceImpl implements SmsTemplateService { @Autowired
private SmsTempletDao smsTempletDao;
@Transactional
public DeleteReply deleteById(IdRequest req) {return SmsTemplateReply.newBuilder().build();}
}

利用 Proxy 部署和设置服务治理端点，进行分层治理，如图所示。

用 Proxy 配合部署形式来兼容 semantic versioning 的版本治理，版本格局有主版本号、次版本号、订正号、版本号递增同时须要备注，规定如下：

• 主版本号：当做了不兼容的 API 批改时，须要递增主版本号。
• 次版本号：当做了向下兼容的功能性新增时，须要递增次版本号。订正号：当做了向下兼容的问题修改时，须要递增订正号。

后行版本号及版本编译信息能够加到“主版本号. 次版本号. 订正号”的前面，作为延长。

五、对微服务的撑持

融数数据 DevOps 体系次要解决的问题是无效地辨认和治理元数据，以便高效、自动化、高质量地将零碎动静组装并运行起来，该体系架构如图所示。

上面联合图对 DevOps 体系做几点阐明。

• 形象了部署的最小单元——包。
• 每个微服务都是由包及其配置组成的，后面提到，服务框架做了代码和配置拆散，因而这里能够将包和包的配置拆散，提供运维便利性。
• 逻辑环境包含了微服务、微服务配置及运行微服务所依赖的 Host 或者 Host Group。
• 版本化逻辑环境，不便回滚。

该体系中的服务组件 =（可运行代码 + 配置）&（依赖 + 配置）&（基础设施 + 配置），如图所示。

从部署的角度讲，无论包还是包的汇合（往往是组成一个独立业务域的独立性能）都须要依附版本能力进行整体部署，能够部署在不同的逻辑环境上，也能够部署在同一个逻辑环境上，如图所示。

六、DevOps 平台总体架构

DevOps 平台通过构建平台将代码编译成物理二进制包，再应用元数据对这个二进制物理包进行形容，造成逻辑包，且将部署、依赖和二进制包自身的元数据对立存储到元数据服务中，最终通过对立环境治理平台读取元数据，按需拉取相应的逻辑包对应的物理包，搁置到指标环境的相应目录下。之后通过过程治理调用相应的服务启动相干微服务，在部署的过程中，由逻辑环境治理绑定 VIP 到微服务的 Proxy 上，将信息注册到 service inventory 服务上，这样 Proxy 和服务 Endpoint 等的运行时信息（例如 IP、端口、版本等）就能够被收集到 service inventory 服务上。

在真正调用服务时通过内建的 Zipkin 能够收集服务调用链的状况，并同 inventory 服务的元数据信息进行匹配，便能够精确地晓得服务调用的关系，从而达到真正的分布式治理；而客户端调用只须要晓得服务所在的逻辑环境信息就能够主动实现服务寻址，这个服务地址就是 Proxy 绑定的 VIP 地址，从而简化客户端调用。DevOps 平台要做的就是保障 Proxy 的健壮性，因为 Proxy 只是简略的反向代理，不存储服务状态，因而只须要做故障漂移就能够了，如图所示。

七、融数数据面向微服务的研发团队介绍

要想胜利地施行微服务架构，仅仅有服务框架、开发平台及 DevOps 平台是不够的，组织和文化也须要适应微服务的需要。依据康威定律，架构由组织决定，因而须要对团队的文化及组织划分构造进行调整。

融数依据 two-pizza team 的准则，依照业务来划分研发团队，建设全栈小团队，从而进步沟通效率、升高沟通老本，具体的团队策略如图所示。

将团队切分后，咱们依照业务线对组织进行架构布局，以便技术团队可能专一于解决对应业务问题（业务驱动，或者说业务优先）。这时，团队外部的设计决策将在团队外部消化，因为团队的规模曾经是 7+/-2 人的量级，因而个别状况下不会对于团队内成员来说过于简单的工作。但团队增多后，团队的协调将是一个问题，因而微服务从技术上帮忙团队将负责的零碎解耦，而打算流程会帮忙团队在工作安顿上找到正当的步骤。

那么，尽管当一个大的业务被合成到各个小团队时，还是会有跨团队的设计工作，然而以上两点是要严格执行的。技术团队和业务团队的单干并非经由下层协调，单方的次要沟通都是团队之间间接进行程度沟通，也就是说，在底层的团队之间，需要、问题和日常交换都间接由业务团队反馈给技术团队的经理，而解决问题时答应业务团队间接接触开发人员，如图所示。

咱们在团队中强调以后果为导向的工作形式，如图所示。

团队成员要有主人翁意识。团队的利益就是集体的利益，团队的胜利才是集体的胜利，团队成员之间要互相帮忙和补位，不容许存在“事不关己，高高挂起”的状况呈现。

在团队中，成员能够发表意见，也能够埋怨，然而不能只停留在语言层面，大家须要口头起来，找到解决问题的办法；咱们心愿每个开发人员都参加架构设计，而不是仅由架构师决定；咱们还强调不要适度设计，激励通过形象和简化解决问题，当然也激励引入新技术，但前提是可能有足够的掌控力而且不影响零碎稳固。

软件工程师负责需要调研、设计、开发、测试、部署、保护、监控、性能降级等一系列的工作，也就是说软件工程师负责利用或者服务的全生命周期的所有工作。运维是团队成员的第一要务。在弱小的自动化运维工具的撑持下，软件工程师必须负责服务或者利用的 SLA。

在团队中引入 oncall 机制，强调保障解决及时性，并引入卓越运维的思维，用数据统计每个团队的线上故障、解决及时性，并逐渐要求故障数量递加，通过弱小的数据反对保障团队解决问题的 SLA，并逐渐改善软件品质。

八、总结

DevOps 的推广是按业务来组织团队，团队蕴含设计、开发、测试、运维等人员，这样一方面能够无效缩小服务外部批改所产生的内耗；另一方面，团队边界能够变得更为清晰。DevOps 理论是一种文化上的变迁，突破了传统开发与运维之间的壁垒，帮忙组织造成从开发、测试到部署、运维这样一个全功能化的高效能团队。

起源：技术琐话，内容选自《架构宝典》

作者：王东

王东，曾任融数数据北京研发核心 CTO，负责微服务、DevOps 以及大数据平台的研发和管理工作。曾供职于 IBM、普元、Amazon、OneAPM 等国内外出名公司。领有 15 年以上的 JavaEE 编程和架构设计教训，精通 DevOps 和微服务，曾领导设计和开发普元 ESB 产品。相熟领取相干的业务流程以及各个银行和领取机构的业务解决模式，相熟利用与领取畛域的大规模分布式系统设计和开发方法，相熟电子商务行业的业务模型。专一于客户行为剖析、营销、产品和服务、客户关系、线上销售、物流配送、渠道整合、供应链集成、售后服务、预测和举荐等各个电子商务次要环节的剖析和设计，以及 IT 零碎的布局和施行。精通 DDD、Scrum 等软方开发和设计方法论。

4 月，【冬哥有话说】DevOps 之庖丁解牛，拆解 DevOps 的工具及具体实战。公众号留言“解牛”可获取地址

• 《数据库继续交付流水线分享与演示（Azure DevOps+Flyway）》
• 《继续交付中的版本治理与基于 Azure DevOps 扩大框架的插件开发》
• 《微服务，多团队合作中的 API 测试怎么做 – Pact 契约测试》
• 《BoatHouse 端到端流水线展现》