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

  • 时间:
  • 浏览:0

不考虑实际业务场景,CAS和Spring Security OAuth相对另外两种框架,无论是集成成本还是可扩展性,都不 明显优势。前文提到,可能性亲戚亲戚一些人确定了Spring Boot作为统一的微服务实现框架,Spring Security OAuth是更自然的确定,但会 维护成本相对低一些(服务端)。

最终方案

最后亲戚亲戚一些人基于Spring Security OAuth框架实现了自己的服务授权中心,鉴权累积目前支持私网认证,Scope校验和域名校验。大致的服务授权流程如下:

设计可能性选型另另一个多 服务注册中心,首如此考虑的全都服务注册与发现机制。纵观当下各种主流的服务注册中心外理方案,大致可归为三类:

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

注2:可能性DNS固有的缓存欠缺,这里不对第三类注册法子作深入探讨。

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

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

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

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

授权中心

有了服务注册中心和配置中心,下一步应该就可不也能 发起服务调用了吧?Wait,还另另一个多多 关键大间题要外理。不同于单体应用內部的法子调用,服务调用所处另另一个多 服务授权的概念。打个比方,那我一家三兄弟住一屋,每次上山打猎喊一声就行,之前 三兄弟分了家,再打猎就要挨家挨户敲门了。你这一 敲一应全都所谓的服务授权。

讲完什么有关微服务的背景知识之前 ,现在就切入今天的正题,面对快速增长的业务需求,小公司要怎样进行微服务化改造?下面就以我在杏仁主导实施的微服务化改造的全过程为背景,给亲戚亲戚一些人简单说一下亲戚亲戚一些人微服务化改造的总体思路和核心上方件的技术选型过程。

项目背景

首先介绍一下微服务化改造的背景。去年年初,在历经2年多的产品迭代之前 ,整个后台应用必须 庞大,可能性成为另另一个多 典型意义上的monolithic application:1. 各个业务模块犬牙交错,重复代码随处可见,补丁代码越打不多;2. 任何另另一个多 改动都时需一次全量发布,哪怕是修改一句文案,极大的拖慢了迭代强度。

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

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

Eureka

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

  • 非开发环境下应用配置的保密性,外理将关键配置写入源代码
  • 不同部署环境下应用配置的隔离性,比如非生产环境的配置必须用于生产环境
  • 同一部署环境下的服务器应用配置的一致性,即所有服务器使用同一份配置
  • 分布式环境下应用配置的可管理性,即提供远程管理配置的能力
现在开源社区主流的配置中心框架有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还提供了一些独有的能力。

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

配置中心

亲戚亲戚一些人知道,大至另另一个多 PaaS平台,小至另另一个多 缓存框架,一般都依赖于特定的配置以正常提供服务,微服务全都例外。

有同学可能性会问,都不 还有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机制就不再适用了,时需引入额外的组件来管理微服务提供者的注册与发现,而你这一 组件全都服务注册中心。

与此一起,可能性公司电商业务变得必须 繁复,老的业务模型必须 难以满足新的需求,急需对原有的订单模块进行重构,可能性抽取另另一个多 独立的订单服务来进行支撑。反复考量之前 ,亲戚亲戚一些人确定了后者。可能性是团队第一次试水微服务,但会 初期人员有限(一人主导,多人配合),最后亲戚亲戚一些人决定走四根比较实用的改良式路线:

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

本文作者:沈斌

  • 注册中心:所有服务注册到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全都为微服务而生。

对应到微服务场景,服务提供方大约上图中的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使用的更为广泛。

限于时间,今天的分享就先到这里。除了上方提到的三大核心组件,删剪的微服务化改造都不 涉及全都一些重要的工作,比如抽取內部类库,创建模板工程,服务调用的限流降级,服务上下文,服务调用链等,之前 有可能性亲戚亲戚一些人再聊。希望今天的分享对你有所帮助,可能性有大间题想和我进一步沟通,欢迎加我微信emacoo。

Q&A

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

严格来说,服务授权饱含鉴权(Authentication)和授权(Authorization)两累积。鉴权外理的是调用方身份识别的大间题,即敲门的是谁。授权外理的是调用是是否被允许的大间题,即让不多进门。两者一先一后,缺一不可。为外理歧义,如不特殊指明,下文所述授权都不 宽泛意义上的授权,即饱含了鉴权。常见的服务授权有两种,简单授权,协议授权和益央授权。

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

OAuth

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