干货 | 基于 DevOps 的微服务生态系统与工程实践（二）

DevOps时代

发布于 2018-02-02 12:06:13

6620

发布于 2018-02-02 12:06:13

文章被收录于专栏：DevOps时代的专栏

上期回顾：干货 | 基于 DevOps 的微服务生态系统与工程实践（一）

前言

从2014年开始，当我接触微服务之后，我发现在微服务的演进过程中，开发和测试、运维需要相亲相爱，紧密合作，才能取得理想的效果。

本系列文章主要包括三部分内容：

第一部分：微服务与 DevOps；第二部分：微服务生态系统；第三部分：微服务架构的工程实践；

本文着重介绍第二部分：微服务生态系统。后续内容请持续关注 DevOps时代公众号。

三、微服务架构的生态系统

我们为什么需要「生态系统」这个词？其实在我过去接触微服务的过程中发现了如果只从架构层面对服务化进行解耦，是很难达到效果的。为什么？

因为当我们把架构拆分成多个模块化之后，如果我的测试，如果我的工具跟不上的话，可能会带来更大的内耗和成本，所以在这过程中，我们需要考虑很多综合的因素。

比如说对于分布式系统之间，因为微服务本质是分布式系统，每个服务都可以独立运行在自己的节点中，这时候我们要考虑分布式系统的同步异步，要考虑经常讨论的数据一致性问题，同时是不是有好的工具链，是不是能够保证这样一个小的服务能够快速上线。

这是一个系统化的工程，已经没有办法割裂来看架构本身，而是从今天讨论的持续集成、DevOps、端到端的交付过程中考虑解耦。

对于今天所处的社区是多元化的社区，工具、框架层出不穷，前端后端数据库都是未来解决方案，这么多如何选择？

如果我们需要去演进微服务架构，我们需要一个什么样的全景图来帮助我们识别这个能力，当有了这个全景图之后，我们可以根据按需选择不同阶段需要引入的不同技术。

基于这两点，我定了微服务的这个生态系统图（上图）。它一共包括五个部分，最上面是现在所讨论的接入层，看到层这个概念，大家不要因为过去的三层变得越来越低效，就抵触层的概念。

3.1 总览

对于接入层，更关心的是如何将用户的请求接入内部系统，这里面典型的是 API goteway、Edge Service。

第二部分是业务层，更关心服务化的方式来服务业务，通过什么样的框架去实现服务。

第三是支撑层，更多描述成今天所面临的分布式系统的挑战，包括服务的协作、安全、路由、告警、监控。

最下面是基础设施，因为对于微服务而言，如果我们希望能够起到效果，一定是基于云，只有云能够帮助我们去降低硬件的伸缩成本。右边是我们在微服务演进过程中非常重要的工程实践和流水线。

3.2 接入层

什么叫「API网关」？其实是帮助系统能够把外界的需求接到内部业务来。

为什么这样做？第一点，今天对于用户端的设备变得越来越多样化，包括手机、IOS、可穿戴设备，这类设备的更新周期可能比较慢，当我们在后端定义了很多服务之后，如果希望 IOS、APP 能够直接访问，对于每一次服务的变更或者服务的UI的变化，都会去触发 APP 本身的变化，而对于IOS审核周期是七天，这对用户的更新会带来非常低的效率，所以我们希望通过这样一种集中化的方式，把用户请求接入进来。

对于 API Gateway，能够跟我们的服务部署在一起，所以服务中的交付效率会远远高于前端设备去跟服务交付，因此我们希望通过这种方式提升交付的效率。随着 APIG 的演进，有很多的框架、工具除了做请求转发，集中化控制以外，会把流量控制、安全认证也放在 APIG 验证层。

3.3 业务层

第二是业务层，我接触到了很多团队，当我们谈到微服务架构的第一反应就是如何解耦架构，我提几个常用的方法论。

对于架构的拆分一开始没有必要非追求完美，我相信在没有做过微服务架构之前，你的60分已经能够让你的系统跑得很顺畅，所以这时候面向对象一定是我们去拆分服务的基准，包括面向对象的动词、名词，名词像订单、库存、用户，动词像支付、登录，都是我们去拆分服务的出发点。

第二是可重用的逻辑，刚才我们讲到在模块化编程的时代，是把通用的逻辑抽象出来进行模块，这也是我们抽象服务的方法论。

第三是资源密集型业务，对于我们的系统是不是有对CPU计算，是不是对可伸缩的需求不一样，也是我们能够去拆分服务的方法论。

最后是领域驱动设计，这是最难的一点，右边的图定义了非常多的概念，包括聚合、实体，很多业界的文章在讲 DDD 是微服务的基础，我觉得这个可能是需要在前期做很多积累的。

对于微服务的实现，刚才讲到对于基础服务而言，我们有很多的框架，这里有一个网址，这里定义了各种语言的微服务框架，我们能够很方便使用他们去开发框架。

在很多场景里我们虽然定义了服务，但是这些服务的功能要组合起来才能提供更多的用户特性，比如我们有订单，有评论，但是当我在手机上显示的时候，希望能够显示这个订单最新的五条评论，可以让手机端去调用两个服务去获取数据，也可以做一个组合服务，它来获取订单，同时获取五条评论再交给前端应用，这就是组合模式的价值。

我们可以使用Proxy、Chained、Shared这些工具。

3.3 支撑层

支撑层是像注册发现，我们为什么要注册发现？在未来，我们的服务上线之后，希望它能够更快、更有效的水平伸缩，但是当我们每做一次伸缩之后，IP地址、服务运行的物理地址是不确定的，所以我们希望通过注册发现的机制，让服务之间相互通信，我可以不用知道这个物理地址，通过注册发现的机制，就能够完成对服务的访问。随着服务数量增多，注册发现机制是我们必须要考虑的方案。

第二是配置更新，对于以前的一个应用而言，我们可以把配置信息写在配置文件里，随着应用一起发布，但是对于可以独立部署的单元越来越多，而且有可能存在一个服务会被多个实例所运行，所以配置更新就变成了挑战。我们过去曾经基于亚马逊的S3做过自己的配置方案。

第三是容错，错误的发生是我们必须要考虑的问题，当我们的请求量过大，当我们的负载过高时我们要考虑如何保证核心业务不被破坏，所以限流、熔断、降级是我们处于微服务规模化之后所面临的新挑战。

3.4 交付流水线与工程实践

3.4.1 微服务开发框架

第四部分是基于交付流水线与工程实践，里面包括了开发框架，交付流水线以及工程实践。

刚才讲到有很多可以利用我们的框架去开发基础服务，这里我抽出了不同语言里面使用量比较高的框架，包括像Java里面的Dropwizard、Spring boot、Scala 里面的 lagom 还有 NODEJS，这些都可以很方便的帮我们从零开始开发微服务。

但是对于企业而言，我们有大量的存量系统，对于使用这类去开发存量系统挑战非常大，因此我们在公司内部有一套开发框架，能够帮助我们把现有的 GARS 方式，能够更快的转换我们的服务，同时提供同步异步以及RPC框架协议，这个可能在七月份左右共享到开源社区，希望大家支持跟关注。

3.4.2 持续交付流水线

“持续交付流水线”这个话题大家应该听到了很多，做的最重要事情就是帮我们把代码提交之后的流程管理起来，最终做到我们能够把这次代码提交的变更发布到类生产或者生产环境上。可以看到右下角是我们定义的 TEST、STAGING 、PRODUCTION，这是通常我们去做产品发布的时候经历的三个环境。

中间的过程是从开发人员到提交代码到CI构建，打包存储的过程，我把它简化了。端到端的工具链，几乎在所有的微服务的成功案例里面，都会讲到他们会不停采用业界先进的工具。

以 Netflix 为例，在它7年的演进过程中贡献了很多的开源组件。包括我们在2013年的时候，最早使用AWS服务的时候，它本身也没有提供好的工具和管理端来管理它的资源，它是帮助我们去做自动化部署创建资源的脚本，所以我们用了很多 Netflix 的开源框架去完成我们的工具链。这里面涉及到编码、构建、测试、部署、发布。