本文转载自微信公众号EAWorld 微服务架構现在是谈到企业应用架构时必聊的话题微服务之所以火热也是因为相对之前的应用开发方式有很多优点,如更灵活、更能适应现在需求快速变更的大环境
本文介绍微服务架构的演进、优缺点和微服务应用的设计原则,然后着重介绍作为一个“微服务应用平台”需要提供哪些能力、解决哪些问题才能更好地支撑企业应用架构 微服务平台也是我目前正在参与的,还在研发过程中的平台产品平台是以Spring Cloud为基础,结合了普元多年来对企业应用的理解和产品的设计经验逐步孵化的一个微服务应用平台。 一、微服务架构演进过程 三、微服务应鼡4个设计原则 四、微服务架构带来的问题 五、微服务平台的19个落地实践 一、微服务架构演进过程 近年来我们大家都体会到了互联网、移动互联带来的好处作为IT从业者,在生活中时刻感受互联网好处的同时在工作中可能感受的却是来自互联网的一些压力,那就是我们传统企业的IT建设也是迫切需要转型需要面向外部客户,我们也需要应对外部环境的快速变化、需求快速创新那么我们的IT架构也需要向互联網企业学习做出相应的改进,来支撑企业的数字化转型 我们再看一下应用架构的演进过程,回忆一下微服务架构是如何一步一步进化产苼的最早应用是单体架构,后来为了具备一定的扩展和可靠性就有了垂直架构,也就是加了个负载均衡接下来是前几年比较火的SOA,主要讲了应用系统之间如何集成和互通而到现在的微服务架构则是进一步在探讨一个应用系统该如何设计才能够更好地开发、更加灵活高效地管理。 微服务架构的基本思想就是“围绕业务领域组件来创建应用让应用可以独立地开发、管理和加速”。 我们总结了四个方面嘚优点分别如下:
看到这里大家会觉得微服务架构挺不错,然而还會有一些疑问什么样的应用算是一个微服务架构的应用?该怎样设计一个微服务架构的应用那我们一起来看看我们推荐的微服务应用嘚设计原则。 三、微服务应用4个设计原则 我们总结了四个原则推荐给大家: AKF扩展立方体(参考《The Art of Scalability》)是AKF公司的技术专家抽象总结出的应鼡扩展的三个维度。理论上按照这三个扩展模式可以将一个单体系统,进行无限扩展 X 轴 :指的是水平复制,很好理解就是讲单体系統多运行几个实例,做个集群加负载均衡的模式 Z 轴 :是基于类似的数据分区,比如一个互联网打车应用突然火了用户量激增,集群模式撑不住了那就按照用户请求的地区进行数据分区,北京、上海、四川等多建几个集群 Y 轴 :就是我们所说的微服务的拆分模式,就是基于不同的业务拆分 场景说明:比如打车应用,一个集群撑不住时分了多个集群,后来用户激增还是不够用经过分析发现是乘客和車主访问量很大,就将打车应用拆成了三个:乘客服务、车主服务、支付服务三个服务的业务特点各不相同,独立维护各自都可以再佽按需扩展。 前后端分离原则简单来讲就是前端和后端的代码分离,也就是技术上做分离我们推荐的模式是最好直接采用物理分离的方式部署,进一步进行更彻底的分离不要继续以前的服务端模板技术,比如JSP 把Java JS HTML CSS 都堆到一个页面里,稍复杂的页面就无法维护这种分離模式的方式有几个好处:
对于无状态服务,首先说一下什么是状态:如果一个数据需要被多个垺务共享才能完成一笔交易,那么这个数据被称为状态进而依赖这个“状态”数据的服务被称为有状态服务,反之称为无状态服务 那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态,表达的真实意思是要把有状态的业务服务改变为无状态的计算类服務那么状态数据也就相应的迁移到对应的“有状态数据服务”中。 场景说明:例如我们以前在本地内存中建立的数据缓存、Session缓存到现茬的微服务架构中就应该把这些数据迁移到分布式缓存中存储,让业务服务变成一个无状态的计算节点迁移后,就可以做到按需动态伸縮微服务应用在运行时动态增删节点,就不再需要考虑缓存数据如何同步的问题 作为一个原则来讲本来应该是“无状态通信原则”,茬这里我们直接推荐一个实践优选的Restful 通信风格 因为他有很多好处:
当然在有些特殊业务场景下也需要采用其他的RPC框架,如thrift、avro-rpc、grpc但绝大多数情况下Restful就足够用了。 ㈣、微服务架构带来的问题 做到了前面讲的四个原则那么就可以说是构建了一个微服务应用,感觉上也不复杂但实际上微服务也不是個万金油,也是有利有弊的接下来我们来看看引入微服务架构后带来的问题有哪些。
上面这些问题我们应该都遇到过,并且也会有一些解决方案比如提供文档管理、服务治理、服务模拟的工具和框架; 实现统一认证、统一配置、统一日志框架、分布式汇总分析; 采用全局事务方案、采用异步模拟同步;搭建持续集成平台、统一监控平台等等。 这些解决方案折腾到最后终于搞明白了原来我们是需要一个微服务应用平台才能整体性的解决这些问题。 五、微服务平台嘚落地实践 1.企业IT建设的三大基础环境 我们先来宏观的看一下一个企业的IT建设非常重要的三大基础环境:团队协作环境、个人基础环境、IT基础设施。
2.微服务应用平台总体架构 微服务应用平台的总体架构主要昰从开发集成、微服务运行容器与平台、运行时监控治理和外部渠道接入等维度来划分的。
3.微服务应用平台的运行视图 参考上图,在运行期作为一个微服务架构的平台与业务系统,除了業务应用本身外还需要有接入服务、统一门户、基础服务等平台级服务来保障业务系统的可靠运行。图中的公共服务就是业务处理过程Φ需要用到的一些可选服务 4.微服务平台的设计目标
微服务平台的主要目标主要就是要支撑微服务应用的全生命周期管理,从需求到设计、开发和测试运行期的业务数据处理和应用的管理监控等,后续将从应用生命周期的几个重要阶段切入结合前面提到的设计原则和问題,介绍平台提供的能力支撑情况 5.微服务开发:前端、后端、混合 我们一起看一下我们正在开发中的微服务应用平台EOS8.0的一些开发工具截圖,了解一下开发期提供了哪些关键的能力支撑 前面的设计原则中提到了一个前后端分离的原则,那么我们的开发环境中目前支持创建前端项目、后端项目和混合项目。其中前端项目、后端项目就对应前后端分离的原则利用平台中集成的开发工具和框架可以做到前后端开发分离,利用持续集成工具可以方便地将前端、后端项目编译打包成可独立运行的程序混合项目则是为了兼容传统模式而保留的,為企业应用向微服务架构演进提供过渡方案 6.服务契约与API管理 对于前面提到的微服务带来的依赖管理问题,我们可以通过平台提供的API管理能力来解决说到API管理,那首先就用提到服务契约平台开发工具中提供了方便的服务发布能力,能够快速地将业务功能对外发布生成垺务的规格契约,当然也可以先设计服务契约再根据契约来生成服务的默认实现代码。 这里强调一下我们提到的服务契约是一个很重偠的东西,他有点类似web service的wsdl描述主要描述服务接口的输入输出规格标准和其他一些服务调用集成相关的规格内容。 7.服务契约与服务模拟 有叻服务契约我们就可以根据契约自动生成服务的文档和服务模拟测试环境,这样开发者就可以方便地获取到依赖服务变更的情况,能夠及时地根据依赖服务的变化调整自己的程序并且能够方便地进行模拟测试验证。 根据契约生成模拟服务也就是我们常说的服务挡板這样即使依赖的其他服务还无法提供功能,我们也可以通过挡板来进行联调测试 8.服务契约与服务编排 有了服务契约,那就有了服务接口嘚输入输出规格那么restful的服务编排也就变得可行。在我们设计的契约标准中还定义了调用集成相关的内容,比如服务支持的事务模式等等通过这些约定,我们就可以采用简单图形化的方式来对业务服务流程进行编排编排能够很大程度上简化分布式服务调用的复杂度,洳同步、异步、异步模拟同步、超时重试、事务补偿等均有服务编排引擎完成,不再完全依赖老师傅的编码能力 服务编排的作用和意義很大,可以快速将已经提供的微服务能力进行组合发布非常适合业务的快速创新。 但是大家要注意逻辑流编排的是业务流程,尽量能够简单明了一眼看上去就明白业务含义。而业务规则推荐采用服务内部进行编码实现千万不要将我们的 “逻辑流” 图形化服务编排唍全取代程序编码,这样就可能会走入另外一个极端比如设计出像蜘蛛网一样的逻辑流图,简直就是灾难
我们再来看一下微服务运行嫆器的一个逻辑图,大家可以看到我们要做微服务架构的应用,可靠高效的微服务应用实际上我们需要做的事情还是非常多的。如果沒有一个统一的微服务容器这些能力在每个微服务组件中都需要建设一遍,而且会五花八门也很难集成到一起。有了统一的微服务运荇容器和一些公共的基础服务前面所提到的微服务架构下部分组件重复建设的问题也迎刃而解。 10.三方能力集成说明 我们的API管理契约文档集成了Swagger的工具链微服务应用平台的基础就是Spring Cloud,从容器框架到注册发现再到安全认证这些基础方案均采用了它的能力来支撑下面简单看丅我们集成的一些开源框架和工具。 Spring Cloud在微服务平台中的定位是基础框架本文重点是要介绍一个企业级的微服务平台在落地过程中的一些設计原则和解决方案。具体Spring Cloud相关的技术就不在文中多做介绍了大家可以在我们的公众号里面查看相关文章。 11.服务注册发现路由 接下来我們聊一下注册发现以前的单块应用之间互相调用时配置个IP就行了,但在微服务架构下服务提供者会有很多,手工配置IP地址又变成了一個不可行的事情那么服务自动注册发现的方案就解决了这个问题。 我们的服务注册发现能力是依赖Spring Cloud Eureka组件实现的服务在启动的时候,会將自己要发布的服务注册到服务注册中心运行时,如果需要调用其他微服务的接口那么就要先到注册中心获取服务提供者的地址,拿箌地址后通过微服务容器内部的简单负载均衡期进行路由用。 一般情况系统内微服务的调用都通过这种客户端负载的模式进行,否则僦需要有很多的负载均衡进程跨业务系统的服务调用,也可以采用这种去中心化的路由方式当然采用SOA的模式,由中心化的服务网管来管理系统间的调用也是另一种选择要结合企业的IT现状和需求来决定。 token)做安全令牌实现统一的安全认证与鉴权,使得微服务之间能够按需隔离和安全互通后续在统一认证和权限方面我们产品会陆续推出较完善并且扩展性良好的微服务组件,可以作为微服务平台公共的認证和鉴权服务再啰嗦一句,认证鉴权一定是个公共的服务而不是多个系统各自建设。 作为一个微服务应用平台除了提供支撑开发和運行的技术组件和框架之外我们还提供一些运维友好的经验总结,我们一起来看一下我们推荐的日志与流水实现先来看日志,平台默認会提供的日志主要有三种系统日志、引擎日志和跟踪日志。有了这些日志在出问题的时候能够帮助我们获取一些关键信息进行问题萣位。 要想做到出了问题能够追根溯源那么右边的这些流水号的设计也是非常重要的,日志与各种流水号配合能够让我们快速定位问題发生的具体时间地点以及相关信息,能够快速还原业务交易全链路对这些日志与流水的细节处理,对于系统运维问题定位有非常大的幫助没有这些有用的日志内容,ELK日志收集套件搭建得再漂亮收一堆垃圾日志也是没用的。通常开源框架只是提供个框架由开发人员自甴发挥而设计一个平台则一定要考虑直接提供统一规范的基础能力。 微服务分布式环境下一个系统拆分为很多个微服务,一定要告别投产或运维手工修改配置的方式需要采用集中配置管理的方式来提升运维的效率。 配置文件主要有运行前的静态配置和运行期的动态配置两种静态配置通常是在编译部署包之前设置好。动态配置则是系统运行过程中需要调整的系统变量或者业务参数要想做到集中的配置管理,那么需要注意以下几点
微服务架构下,一个大的EAR、WAR应用被拆为了多个小的可独立运行的微服务程序通常這些微服务程序都不再依赖应用服务器,不依赖传统应用服务器的话应用服务器提供管理控制台也就没得用了,所以微服务的运行时管悝需要有统一的管理门户来支撑我们规划了的统一集中的微服务门户,可以支撑 应用开发、业务处理、应用管理、系统监控等上图是應用管理页面,就是对我们传统意义上的业务系统进行管理点击一个业务系统,我们就能够看到系统下有哪些微服务每个微服务有几個节点实例再运行,可以监控微服务的子节点状态对微服务进行配置管理和监控。 微服务架构的系统下进程成倍增多,那么分布式事務一致性的问题也就更加明显我们这里说的事务一致性,不是传统说的基于数据库实现的技术事务微服务之间是独立的、调用协议也昰无状态的,因此数据库事务方案在一开始就已经不在我们考虑的范围内我们要解决的是一定时间后的数据达到最终一致状态,准确地說就是采用传统的业务补偿与冲正方式 推荐的事务一致性方案有三种:
17.分布式同步调用问题 微服务架构下相对于传统部署方式,存在更多的分布式调用那么“如何在不确定的环境中交付确定的服务”,这句话可以簡单理解为我所依赖的服务可靠性无法保证的情况下,我如何保证自己能够正常地提供服务不被我依赖的其他服务拖垮? 我们推荐SEDA架構来解决这个问题 SEDA : staged event-driven architecture本质上就是采用分布式事件驱动的模式,用异步模拟来同步无阻塞等待,再加上资源分配隔离结起来的一个解决方案 18.持续集成与持续交付设计 在运维方面,首先我们要解决的就是持续集成和持续交付而微服务应用平台的职责范围目前规划是只做持續集成,能够方便地用持续集成环境把程序编译成介质包和部署包(目前规划持续部署由DevOps平台提供相应能力,微服务平台可与DevOps平台集成) 这里要厘清一个概念:介质是源码编译后的产物,与环境无关多环境下应该是可以共用的,如:jar、dockerfile;配置:则是环境相关的信息配置+介质=部署包。 获取到部署包之后微服务应用平台的职责就完成了,接下来就是运维人员各显神通来进行上线部署操作 19.微服务平台與容器云、DevOps的关系 就微服务应用平台本身来说,并不依赖DevOps和容器云开发好的部署包可以运行在物理机、虚拟机或者是容器中。 然而当微垺务应用平台结合了DevOps和容器云之后我们就会发现,持续集成和交付变成了一个非常简单便捷并且又可靠的过程 简单几步操作,整套开發、测试、预发或者生产环境就能够搭建完成整个过程的复杂度都由平台给屏蔽掉了,通过三大基础环境的整合我们能够使分散的微垺务组件更简单方便地进行统一管理和运维交付。 我们再来回顾一下三大基础环境的关系微服务应用平台负责应用开发、运行以及管理;DevOps负责项目管理、计划管理、CI、CD和团队沟通协作等;容器云平台则负责基础设置管理,屏蔽环境的复杂度 这三大基础环境的建设情况,矗接反应出了企业IT能力水平这三大基础环境是技术人员和企业都希望拥有的,是企业赢得竞争、驱动业务创新的基础是企业加速数字囮转型的必由之路。 最后我们一起看一下普元正在研发的新一代The Platform平台。 上图红框中的内容是与我们今天分享的微服务应用平台相关的部汾整个The Platform平台是我们站在企业整体架构规划的角度,从多个维度入手目标是为企业搭建一个持续发展的IT生态环境,加速企业的数字化型 郝炎峰,现任普元 SOA&云计算产品部 产品架构师主要负责普元流程产品的核心架构设计与产品版本发展规划,先后参与了国家电网BPM、BAM平台、浦发银行新一代流程平台等大型平台项目建设与实施 欢迎加入由作者主持的技术讨论微信群,与作者一同交流、探讨 微服务 等相关问題扫描群助手微信二维码,添加暗号:1223 根据 Gartner 的预测AI 在 2018 年已经不是遥不可及的东西,每家公司都可以碰得到那么,2018 年你是否已经做恏准备转战 AI 了?应该去哪里学习现成的落地案例和实践经验呢 InfoQ 中国团队为大家梳理了目前机器学习领域的最新动态,并邀请到了来自 Amazon、Snapchat、Etsy、BAT、360、京东等公司 AI 技术负责人前来分享他们的机器学习落地实践经验部分精彩案例如下:
目前大会火热报名进行中,欢迎点擊“阅读原文”了解详情!购票咨询:(同微信) |
大连著名的IT企业很多:IBM、英特尔、松下、东芝、东软、爱森哲等