基于 DevOps 的微服务生态系统与工程实践(二)

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

本文来自于 GOPS 2017 深圳站的演讲《基于 DevOps 的微服务生态系统与工程实践》,DevOps时代公众号连续三篇文章详细解读DevOps与微服务的秘密。

作者简介:

王磊 华为 中央软件院首席软件工程技术专家 国内首批 DevOps Master 认证讲师,《DevOps Handbook》中文译者。 并著有国内首本微服务架构相关书籍《微服务架构与实践》一书。

前言

从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 的开源框架去完成我们的工具链。这里面涉及到编码、构建、测试、部署、发布。

3.5 基础设施

最底下的是基础设施层,对于微服务我们希望做的是能够快速交付和帮助我们在很多不确定的场景做水平伸缩。随着我们未来做试验、做创新的需求越来越强烈,我们希望上线之后,我的用户是一万的时候能够满足,一百万的时候也能满足。

所以对于伸缩而言,一定要借助于底层的基础设施,公有云,私有云,都是不错的选择。

四、微服务架构的工程实践

最后是微服务架构的工程实践。这是 Netflix 从09到16年七年时间,把他的业务从数据中心迁到 AWS 之后的架构图。对于我们的系统而言,是不是意味着当我们把架构拆分成50个、100个之后,也能获取到这样收益呢?

这是很多组织和团队在做微服务的时候考虑的第一个问题。如果我们把架构拆成50个,100个,是否能获得同样的收益?答案是否定的。Netflix 首席云架构师说过,他们做了大量的关于流程工具和实践的演进。

微服务架构工程实践更多干货请关注后续文章

五、总结

最后推荐几本书,大部分是关于持续交付和 DevOps 的书籍,不管我们如何清晰定义概念的划分,但是实践过程中三者是密不可分的。

本文来自:DevOps时代社区

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏云计算D1net

云备份可以降低备份存储成本吗?

数据保护最昂贵的成本之一是所有数据副本的存储成本。备份存储容量可能是主存储容量的10倍或更多。备份存储需要企业具有极高的IT预算和数据中心机房空间。 ? 而数据...

35711
来自专栏腾讯云服务器团队的专栏

腾讯云批量计算:用搭积木的方式构建高性能计算系统

高性能计算(High Performance Computing)简称 HPC,在气象预测、地震预警、生命科学、军事、航天等高科技领域有着广泛的应用,其代表超级...

5294
来自专栏DevOps时代的专栏

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

上期回顾:干货 | 基于 DevOps 的微服务生态系统与工程实践(一) 前言 从2014年开始,当我接触微服务之后,我发现在微服务的演进过程中,开发和测试、运...

1837
来自专栏大数据

大数据架构最佳实践

原文地址:https://dzone.com/articles/big-data-architecture-best

1544
来自专栏数据和云

遇见未来 | 对话王璞:谈分布式系统在企业落地的挑战

分布式的概念很早就有了,然而真正在企业中得以广泛应用却是最近几年的事情。互联网的深入深化及大数据应用的兴起,对于IT系统的处理能力及效率都提出了更高的要求。通过...

2954
来自专栏哲学驱动设计

OEA中的AutoUI重构(3)- 评审会议后的设计

    上篇文章《OEA中的AutoUI重构(2)- 评审会议前的总体设计》写了在“OEA框架”中进行AutoUI模块重构的设计方案。最近项目组已经召开了评审会...

1746
来自专栏北京马哥教育

史上最全互联网运维工作规划!十分钟找到职业方向!

互联网运维工作,以服务为中心,以稳定、安全、高效为三个基本点,确保公司的互联网业务能够7×24小时为用户提供高质量的服务。 运维人员对公司互联网业务所依赖的基础...

42811
来自专栏Java职业技术分享

Java后端技术栈,到底如何深入学习?

很多人做Java开发4,5年后,都会感觉自己遇到瓶颈。什么都会又什么都不会,如何改变困境,为什么很多人写了7,8年还是一个码农,工作中太多被动是因为不懂底层原理...

310
来自专栏SDNLAB

IT变革?SDN时代的企业网络管理系统

编者按:现在整个业界正经历着一个变革,我们正在做的包括部署虚拟网络、移动设备和云服务都是为了实现软件定义网络(SDN),这将是网络发展的下一个时代,这就要求网络...

2525
来自专栏程序员的SOD蜜

2010技术应用计划

导读: “2010技术应用计划”是去年3月中心部门头脑风暴“成果”的一部分,现在重新回顾一下,当时的许多计划或许对现在及以后还有一定的意义,故放在我的博客“朝花...

1826

扫码关注云+社区