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

  • 时间:
  • 浏览:0
  • 来源:大发5分快乐8_大发5分快乐8官方

  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机制就不再适用了,都要引入额外的组件来管理微服务提供者的注册与发现,而你你这个 组件只是服务注册中心。

限于时间,今天的分享就先到这里。除了上边提到的三大核心组件,完正的微服务化改造也有涉及什么都有有一些重要的工作,比如抽取内部内部结构类库,创建模板工程,服务调用的限流降级,服务上下文,服务调用链等,过后 有肯能亲戚亲戚朋友再聊。希望今天的分享对你有所帮助,肯能有难题想和我进一步沟通,欢迎加我微信emacoo。

Q&A

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

本文来自云栖社区商务商务合作伙伴Dockerone.io,了解相关信息还都要关注Dockerone.io。

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

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

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

不考虑实际业务场景,CAS和Spring Security OAuth相对另外有四种 框架,无论是集成成本还是可扩展性,也有明显优势。前文提到,肯能亲戚亲戚朋友取舍了Spring Boot作为统一的微服务实现框架,Spring Security OAuth是更自然的取舍,过后 维护成本相对低一些(服务端)。

最终方案

最后亲戚亲戚朋友基于Spring Security OAuth框架实现了买车人的服务授权中心,鉴权偏离 目前支持私网认证,Scope校验和域名校验。大致的服务授权流程如下:

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

授权中心

有了服务注册中心和配置中心,下一步应该就还都要发起服务调用了吧?Wait,还有有一另另一一二个多关键难题要解决。不同于单体应用内部内部结构的最好的方法调用,服务调用居于有一另另一一二个多服务授权的概念。打个比方,只是一家三兄弟住一屋,每次上山打猎喊一声就行,过后 三兄弟分了家,再打猎就要挨家挨户敲门了。你你这个 敲一应只是所谓的服务授权。

严格来说,服务授权中含鉴权(Authentication)和授权(Authorization)两偏离 。鉴权解决的是调用方身份识别的难题,即敲门的是谁。授权解决的是调用是有无被允许的难题,即让不用进门。两者一先一后,缺一不可。为解决歧义,如不特殊指明,下文所述授权也有宽泛意义上的授权,即中含了鉴权。常见的服务授权有有四种 ,简单授权,协议授权和珍央授权。

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

OAuth

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

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

讲完哪哪十几个 有关微服务的背景知识过后 ,现在就切入今天的正题,面对快速增长的业务需求,小公司何如进行微服务化改造?下面就以我在杏仁主导实施的微服务化改造的全过程为背景,给亲戚亲戚朋友简单说一下亲戚亲戚朋友微服务化改造的总体思路和核心上边件的技术选型过程。

项目背景

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

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

Eureka

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

与此一同,肯能公司电商业务变得没有 简化,老的业务模型没有 难以满足新的需求,急需对原有的订单模块进行重构,肯能抽取有一另另一一二个多独立的订单服务来进行支撑。反复考量过后 ,亲戚亲戚朋友取舍了后者。肯能是团队第一次试水微服务,过后 初期人员有限(一人主导,多人配合),最后亲戚亲戚朋友决定走十根比较实用的改良式路线:

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

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

本文作者:沈斌

设计肯能选型有一另另一一二个多服务注册中心,首太难考虑的只是服务注册与发现机制。纵观当下各种主流的服务注册中心解决方案,大致可归为三类:

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

注2:肯能DNS固有的缓存居于问题,这里不对第三类注册最好的方法作深入探讨。

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