DockOne微信分享(一四五):乐高式微服务化改造

  • 时间:
  • 浏览:1

与此一块儿,怎么才能 会让公司电商业务变得真难复杂,老的业务模型真难难以满足新的需求,急需对原有的订单模块进行重构,怎么才能 会让抽取有另另有一一二个独立的订单服务来进行支撑。反复考量以前,我们儿选者了后者。怎么才能 会让是团队第一次试水微服务,怎么才能 会让初期人员有限(一人主导,多人配合),最后我们儿决定走四根比较实用的改良式路线:

  • 最小化对已有应用的侵入性
  • 偏好主流的微服务框架
  • 只做必要的微服务治理
第四根定下了此次改造的基调,降低了方案无法落地的风险,确保了项目的整体可行性。第二条我们儿站在巨人的肩膀上,不重复造轮子,聚焦在哪哪几个的间题五种 ,而全是工具。第三条缩减项目范围,处里过度工程,以战养兵,不打无用之仗。下图展示了目前杏仁微服务的整体架构,而今天的分享将着重介绍其中的三大核心组件,即注册中心,配置中心和授权中心。

small对应的假若微服务的微,全都初次接触微服务的同学对微的理解往往会守候在实现层面,以为代码少假若微,但实际上,这里的微更多的是体现在逻辑层面。微服务的有另另有一一二个重要设计原则是share as little as possible,哪哪几个意思呢?假若说每个微服务应该设计成边界清晰不重叠,数据独享不共享,也假若我们儿常说的高内聚、低耦合。保证了small,不让 做到independently deployable。而实现automated deployment的关键是DevOps文化。须要提醒的是,随着业务复杂度的上升,有另另有一一二个微服务怎么才能 会让须要拆分为更多更细粒度的微服务,比方说,一结束了了英语 假若有另另有一一二个简单的订单服务,中间逐步拆分出清算,支付,结算,对账等许多服务。从本质上来看,相对单体应用,微服务是以牺牲强一致性、提高部署复杂为代价,换取更彻底的分布式社会形态,比如异构性和强隔离性。对应CAP理论,假若用Consistency换Partition。异构性比较容易理解,通过定义统一的API规范(一般采用REST风格),每个微服务团队可不须要根据个人 的能力矩阵选者最适合的技术栈,而全是个人 须要使用相同的技术栈。强隔离性指的是,对于有另另有一一二个典型的单体应用,隔离性最高非要体现到模块级别,怎么才能 会让共享同有另另有一一二个代码仓库,模块的边界往往比较模糊,须要人为定义全都规范来保证良好的隔离性,但无论怎么才能 才能 强调,稍一疏忽,就会产生“越界”行为,时间愈长,维护隔离性的成本愈高。而到了微服务阶段,自带应用级别的隔离性,“越界”的成本大大提升,不让任何规范,架构五种 就保证了隔离性。我个人 面,怎么才能 会让采用了分布式架构,微服务无法再简单的通过数据库事务来保证强一致性,假若通过消息中间件怎么才能 会让五种 事务补偿机制来保证最终一致性,比如微信我们圈的点赞,淘宝订单的物流情况报告。其次,在微服务阶段,随着应用数量的激增,一次发布往往涉及多个应用,加在异构性带来的部署最好的办法 的多样性,对团队的运维水平尤其是自动化水平提出了更高的要求,运维和开发的边界进一步模糊。

原文发布时间为:2017-10-10

原文标题:DockOne微信分享(一四五):乐高式微服务化改造

有同学怎么才能 会让会问,全是还有DubboSpring Cloud吗?Dubbo是阿里开源的第一代RPC框架,早在2011年就怎么才能 会让发布了2.0版本,三年后也假若2014年,Martin Fowler才提出了微服务的概念。其实用Dubbo不让 开发微服务,但这就好比用EJB的规范去开发Spring Bean,怎么才能 会用怎么才能 会别扭。Dubbo最大的哪哪几个的间题是升级缓慢,最近一次发布还是2014年10月,支持的Spring版本是2.5.6.SEC03,要知道Spring 5都快出来了。Spring Cloud可不须要说是目前Java社区最好最完整版的微服务框架(真难之一),底层用的也是Spring Boot,照着Spring Cloud的新手指南,分分钟就可不须要搭建出一整套微服务应用,非常适合改革式但全是改良式的微服务改造,怎么才能 会让非Spring应用难以集成。作为硬币的另一面,选者Spring Boot,是因为我们儿须要做几滴 的自定义工作,以弥补Spring Boot在微服务治理方面所欠缺的能力,比如接下来要说的注册中心、配置中心和授权中心。这也是为哪哪几个今天的分享标题起名乐高式微服务化改造。

注册中心

作为微服务架构最基础也是最重要的组件之一,服务注册中心本质上是为了解耦服务提供者和服务消费者。对于任何有另另有一一二个微服务,原则上都应居于怎么才能 会让支持多个提供者,这是由微服务的分布式属性决定的。更进一步,为了支持弹性扩缩容社会形态,有另另有一一二个微服务的提供者的数量和分布往往是动态变化的,也是无法预先选者的。怎么才能 会让,那我在单体应用阶段常用的静态LB机制就不再适用了,须要引入额外的组件来管理微服务提供者的注册与发现,而你五种 组件假若服务注册中心。

本文作者:沈斌

不考虑实际业务场景,CAS和Spring Security OAuth相对另外五种 框架,无论是集成成本还是可扩展性,全是明显优势。前文提到,怎么才能 会让我们儿选者了Spring Boot作为统一的微服务实现框架,Spring Security OAuth是更自然的选者,怎么才能 会让维护成本相对低许多(服务端)。

最终方案

最后我们儿基于Spring Security OAuth框架实现了我个人 的服务授权中心,鉴权主次目前支持私网认证,Scope校验和域名校验。大致的服务授权流程如下:

  • 注册中心:所有服务注册到Consul集群,怎么才能 会让通过Consul Template刷新Nginx配置实现负载均衡
  • 配置中心:使用自研的Matrix系统,通过自定义构建插件覆写配置,最小化对已有应用的侵入性
  • 授权中心:基于Spring Security OAuth,一块儿支持基于微信企业号的SSO

基本框架

基本框架我们儿选者的是Spring Boot。Spring Boot是Spring开源社区提供的有另另有一一二个去容器、去XML配置的应用框架。和标准的基于war包的Web应用相比,Spring Boot应用可不须要直接以java -jar的最好的办法 运行,也假若说不再须要部署到有另另有一一二个独立的Web容器(比如Tomcat)中不让 运行。其眼前 的运行机制简单来说假若,当有另另有一一二个Spring Boot应用启动时,在加载完核心框架类以前,会启动有另另有一一二个内嵌的Web容器(默认是Tomcat),怎么才能 会让加在载应用五种 的各种配置类和Bean。也假若说不再是容器包应用,假若应用包容器。正是怎么才能 会我不让五种 社会形态,Spring Boot非常适用于开发微服务,毫不夸张的说Spring Boot假若为微服务而生。

  • 测活:服务注册以前,怎么才能 才能 对服务进行测活以保证服务的可用性?
  • 负载均衡:当居于多个服务提供者时,怎么才能 才能 均衡各个提供者的负载?
  • 集成:在服务提供端怎么才能 会让调用端,怎么才能 才能 集成注册中心?
  • 运行时依赖:引入注册中心以前,对应用的运行时环境有何影响?
  • 可用性:怎么才能 才能 保证注册中心五种 的可用性,特别是消除单点故障?
下面就围绕这哪几个方面,简单分析一下Eureka,SmartStack,Consul的利弊。

Eureka

从设计宽度来看,Eureka可不须要说是无懈可击,注册中心、提供者、调用者边界清晰,通过去中心化的集群支持保证了注册中心的整体可用性,但缺点是Eureka属于应用内的注册最好的办法 ,对应用的侵入性太强,且只支持Java应用。

设计怎么才能 会让选型有另另有一一二个服务注册中心,首真难考虑的假若服务注册与发现机制。纵观当下各种主流的服务注册中心处里方案,大致可归为三类:

  • 应用内:直接集成到应用中,依赖于应用自身完成服务的注册与发现,最典型的是Netflix提供的Eureka
  • 应用外:把应用当成黑盒,通过应用外的五种 机制将服务注册到注册中心,最小化对应用的侵入性,比如Airbnb的SmartStack,HashiCorp的Consul
  • DNS:将服务注册为DNS的SRV记录,严格来说,是五种 特殊的应用外注册最好的办法 ,SkyDNS是其中的代表
注1:对于第一类注册最好的办法 ,除了Eureka你五种 一站式处里方案,还可不须要基于ZooKeeper怎么才能 会让Etcd自行实现一套服务注册机制,这在大公司比较常见,但对于小公司而言显然性价比太低。

注2:怎么才能 会让DNS固有的缓存欠缺,这里不对第三类注册最好的办法 作深入探讨。

  1. 最小化对已有应用的侵入性,这也是贯穿我们儿整个微服务化改造的原则之一。
  2. 降低运维的复杂度,通过使用Registrator和Consul Template实现服务自注册和自发现。

配置中心

我们儿知道,大至有另另有一一二个PaaS平台,小至有另另有一一二个缓存框架,一般都依赖于特定的配置以正常提供服务,微服务假若例外。

  • 非开发环境下应用配置的保密性,处里将关键配置写入源代码
  • 不同部署环境下应用配置的隔离性,比如非生产环境的配置非要用于生产环境
  • 同一部署环境下的服务器应用配置的一致性,即所有服务器使用同一份配置
  • 分布式环境下应用配置的可管理性,即提供远程管理配置的能力
现在开源社区主流的配置中心框架有Spring Cloud Config和disconf,两者都满足了上述有另另有一一二个核心需求,但又有所区别。Spring Cloud ConfigSpring Cloud Config可不须要说是有另另有一一二个为Spring量身定做的轻量级配置中心,巧妙的将应用运行环境映射为profile,应用版本映射为label。在服务端,基于特定的内部人员系统(Git、文件系统怎么才能 会让Vault)存储和管理应用配置;在客户端,利用强大的Spring配置系统,在运行时加载应用配置。DisconfDisconf是前百度资深研发工程师廖绮绮的开源作品。在服务端,提供了完善的操作界面管理各种运行环境,应用和配置文件;在客户端,宽度集成Spring,通过Spring AOP实现应用配置的自动加载和刷新。

最终方案

不管是Spring Cloud Config还是Disconf,默认提供的客户端都宽度绑定了Spring框架,这对非Spring应用而言无疑增加了集成成本,即便它们都提供了获取应用配置的API。最终我们儿还是选者了微服务化改造以前自研的Matrix作为配置中心,一方面,可不须要保持新老系统使用同一套配置服务,降低维护成本,我个人 面,在满足有另另有一一二个核心需求的前提下,Matrix还提供了许多独有的能力。

讲完哪哪几个有关微服务的背景知识以前,现在就切入今天的正题,面对快速增长的业务需求,小公司怎么才能 才能 进行微服务化改造?下面就以我在杏仁主导实施的微服务化改造的全过程为背景,给我们儿简单说一下我们儿微服务化改造的总体思路和核心中间件的技术选型过程。

项目背景

首先介绍一下微服务化改造的背景。去年年初,在历经2年多的产品迭代以前,整个后台应用真难庞大,怎么才能 会让成为有另另有一一二个典型意义上的monolithic application:1. 各个业务模块犬牙交错,重复代码随处可见,补丁代码越打太少;2. 任何有另另有一一二个改动都须要一次全量发布,哪怕是修改一句文案,极大的拖慢了迭代下行速率 。

严格来说,服务授权饱含鉴权(Authentication)和授权(Authorization)两主次。鉴权处里的是调用方身份识别的哪哪几个的间题,即敲门的是谁。授权处里的是调用否是被允许的哪哪几个的间题,即让不让进门。两者一先一后,缺一不可。为处里歧义,如不特殊指明,下文所述授权全是宽泛意义上的授权,即饱含了鉴权。常见的服务授权有五种 ,简单授权,协议授权跟生央授权。

  • 简单授权:服务提供方暂且进行真正的授权,假若依赖于内部人员环境进行自动授权,比如IP地址白名单,内网域名等。这就好比三兄弟互相留了有另另有一一二个后门。
  • 协议授权:服务提供方和服务调用方以前约定有另另有一一二个密钥,服务调用方每次发起服务调用请求时,用约定的密钥对请求内容进行加密生成鉴权头(饱含调用方唯一识别ID),服务提供方收到请求后,根据鉴权头找到相应的密钥对请求进行鉴权,鉴权通以前再决定否是授权此次调用。这就好比三兄弟之间约定敲一声是大哥,敲两声是二哥,敲三声是三弟。
  • 中央授权:引入独立的授权中心,服务调用方每次发起服务调用请求时,先从授权中心获取有另另有一一二个授权码,怎么才能 会让附在原始请求上一块儿发给服务提供方,提供方收到请求后,先通过授权中心将授权码还原成调用方身份信息和相应的权限列表,怎么才能 会让决定否是授权此次调用。这就好比三兄弟每家家门口安装了有另另有一一二个110联网的指纹识别器,通过远程指纹识别敲门人的身份。
一般来说,简单授权在业务规则简单、安全性要求不高的场景下用的比较多。而协议授权,比较适用于点对点怎么才能 会让C/S架构的服务调用场景,比如Amazon S3 API。对于网状社会形态的微服务而言,中央授权是五种 最好的办法 中最适合也是最灵活的选者:
  1. 复杂了服务提供方的实现,让提供方专注于权限设计而非实现。
  2. 更重要的是提供了一套独立于服务提供方和服务调用方的授权机制,不让重新发布服务,假若在授权中心修改服务授权规则,就可不须要影响后续的服务调用。

OAuth

说起具体的授权协议,全都人第一反应假若OAuth。事实上也的确真难,全都互联网公司的开放平台全是基于OAuth协议实现的,比如Google APIs微信网页授权接口。一次标准的OAuth授权过程如下:

本文来自云栖社区媒体公司合作 伙伴Dockerone.io,了解相关信息可不须要关注Dockerone.io。

  • 分离配置文件和配置项。对于配置文件,通过各类配套打包插件(SBT,Maven,Gradle),在打包时将配置文件打入应用包中,一块儿最小化对CI的侵入性;对于配置项,提供SDK,帮助应用从服务端获取配置项,一块儿支持简单的缓存机制。
  • 增加应用版本维度,即对于同一应用,可不须要在服务端针对不同版本或版本区间维护不同的应用配置。
  • 应用配置的版本化支持,同类于Git,可不须要将任一应用配置回退到任一历史版本。

授权中心

有了服务注册中心和配置中心,下一步应该就可不须要发起服务调用了吧?Wait,还有有另另有一一二个关键哪哪几个的间题要处里。不同于单体应用内部人员的最好的办法 调用,服务调用居于有另另有一一二个服务授权的概念。打个比方,那我一家三兄弟住一屋,每次上山打猎喊一声就行,很久三兄弟分了家,再打猎就要挨家挨户敲门了。你五种 敲一应假若所谓的服务授权。

限于时间,今天的分享就先到这里。除了中间提到的三大核心组件,完整版的微服务化改造一定会涉及全都许多重要的工作,比如抽取内部人员类库,创建模板工程,服务调用的限流降级,服务上下文,服务调用链等,以前有怎么才能 会让我们儿再聊。希望今天的分享对你有所帮助,怎么才能 会让有哪哪几个的间题想和我进一步沟通,欢迎加我微信emacoo。

Q&A

Q:配置中心使用Consul的配置共享,有真难考虑过?

对应到微服务场景,服务提供方相当于上图中的Resource Server,服务调用方相当于Client,而授权中心相当于Authorization Server和Resource Owner的合体。

Beared Token

在标准的OAuth授权过程中,Resource Server收到Client发来的请求后,须要到Authorization Server验证Access Token,并获取Client的进一步信息。通过OAuth 2.0版本引入中的Beared Token,我们儿可不须要省去你五种 次调用,将Client信息存入Access Token,并在Resource Server端完成Access Token的鉴权。主流的Beared Token有SAMLJWT五种 格式,SAML基于XML,而JWT基于JSON。怎么才能 会让大多数微服务都使用JSON作为序列化格式,JWT使用的更为广泛。