微服务架构与实践

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/English0523/article/details/52700216

摘要:微服务出现的时间不短了,但是为什么现在才这么重视它?互联网转型要转型什么?

微服务出现的时间不短了,但是为什么现在才这么重视它?互联网转型要转型什么?

第一,以职能为中心转向以用户为中心。我们过去的信息化更多的是依照部门职能,有什么样的工作内容,有什么样的流程,然后去做系统。下一步的信息化更多的是以用户为中心。为什么是以用户为中心?我们要看用户到底需要什么,在什么样的场景下需要什么样的信息支持。过去我们只在内部做很多系统,其实用户体验也非常的不好,用户需要的东西也没有。

第二,从流程驱动转向数据驱动。过去都是看业务流程是什么样的,流程中间需要什么样的数据来支持。随着移动互联网、物联网这些数据的产生,根据数据的分析判断或者驱动新的流程,所以新的应用场景是由数据来驱动的。

第三,从事后录单转向现场数据自动采集。过去的信息化都是靠人工输入,发生的业务就输入一些信息进去。今后由于移动互联网和物联网实时数据的采集,我们做好实时的在现场的采集,反而不需要人工做采集、手工录入。

第四,从封闭系统转向开放系统。过去的系统都是封闭式的,开发它的时候没有考虑到开放、没有考虑到互联或者被谁调用。今后的系统开发出来,应该是微服务的方式,它是暴露API,某个系统不需要知道被谁调用、被调用多少次,该系统在开发时就做到是一个开放的系统,暴露API。

第五,从单机架构转向分布式架构。总体来讲,过去的信息化都是基于单机的架构,俗称叫IOE架构,在单机上做的整个基础设施,包括上面的应用、数据库都是基于IOE结构写的,下一步要转向分布式。分布式是从基础设施一直到应用都要做到分布式。为什么要转向分布式?是因为要做到弹性可扩展,满足大量的并发、交互和大的用户量和数据量。

第六,从中心化治理转向去中心化自治。过去的信息化走到今天,到SOA这样一个阶段大家知道仍是中心化治理的阶段,依靠总线来做交互、路由;下一步在微服务的模式下是事件的驱动,服务之间他们如何去被调用、如何去走流程是通过事件驱动的,而不是中心化的思路做治理,更多的是去中心化的自治。

举例:美国GE说,GE未来是一个软件企业,为什么?因为所有一切是被软件所定义,背后是云平台、大数据平台的支撑。GE打造的工业互联网平台:前端通过连接所有的设备、资产,端到端所有跨业务流程的,包括合作伙伴、客户所有这些东西都通过云平台的连接,设备产生的数据、产品的数据都基于云方式存储。在云上,有了数据,数据驱动各种创新的应用,通过融合分析可以得出很多的洞察,包括设备的可预测性维护等等。这个工业互联网平台底层就是PaaS和IaaS,上面就是微服务的架构。整个应用架构是朝微服务的方式转型,不管是对资产的,就是设备、装备还有各种分析的服务、数据存储服务、安全服务、运营服务都是基于这样一个平台在打造下一代微服务的架构、微服务的应用。数据架构方面从融合的大数据架构转型。通过物联感知,各种各样的数据在产生,这些数据通过数据的管道结构化,这些结构化的数据怎么存储、非结构的数据怎么存储,对于需要实时处理的数据怎么存储计算,对于一些不需要实时处理的数据怎么存储,这里面会进入到一个融合的大数据的架构基础上去做数据的存储和计算。有了数据的基础上我们再做一些分析和利用,支持或是引导业务变革和创新。

从以上互联网转型我们就可以看到为什么需要微服务的架构:

第一,快速的创新。在互联网时代我们需要快速的创新。不像过去,我们做一个系统花了很长时间,半年甚至一年实施出来,为时晚矣。信息时代,我们需要快速的响应和交付。

第二,随时随地的服务需要随时的连接。

第三,网络的规模。也就是说我们的服务,我们可能随时要被大量的人访问、数据随时大量的产生,这样一种大量数据的产生、大量用户访问的规模也需要有一种新的弹性架构支撑它。

第四,以移动为中心的用户体验。所有这些导致我们要基于微服务架构构建一种原生的云应用。所谓原生的云应用,就是在互联网的基础平台上基于微服务架构开发的应用,它是弹性可扩展的,可以支持大并发大交互。

总之,未来业务的敏捷一定要依赖于IT的敏捷,我们一直追求敏捷的IT:一个弹性可扩展的云计算与大数据基础平台(IaaS + PaaS),加上基于微服务架构的原生云应用(SaaS)开发,这已成为企业级IT的必然选择!

【案例分析】

好雨云的微服务架构实践

微服务从去年以来一直受到众多开发者的热捧,目前国外使用微服务架构的知名厂商中不乏Amazon、Twitter、Netflix等这样的科技巨头,但是国内在微服务领域实践这块

  微服务从去年以来一直受到众多开发者的热捧,目前国外使用微服务架构的知名厂商中不乏Amazon、Twitter、Netflix等这样的科技巨头,但是国内在微服务领域实践这块,真正成功的案例屈指可数,好雨云平台强调应用一键部署,整个平台的核心正是基于微服务的架构去搭建,可以说,好雨云在微服务领域有着成功的经验和技术。

  那么好雨云究竟是一个怎样的平台呢,据该平台创始人刘凡介绍,好雨云平台是提供一站式,开发、部署、运行和伸缩任何类型应用的云平台,强调应用的一键部署,同时,好雨云平台还提供数据服务、开发工具和企业信息服务,为产品和企业发展提供全方位支持。 目前和好雨云平台类似的国外有Heroku和IBM BlueMix。

  对于有着超过12年互联网产品开发和管理经验刘凡来说,选择PaaS领域创业并非偶然,在澳客网的时候,他发现企业在产品开发的过程中,浪费了大量的时间在申请服务器、安装各种依赖服务、配置开发环境、写构建脚本等上面,当时就思考如果能把每个团队重复做的事情和有难度的技术问题,做成一个可重用的轮子,产品团队只要专注于产品本身,那产品的开发效率将大大提升,试错成本也将更低,于是,他和几位有类似想法的小伙伴离开了澳客网,创办了好雨云。

  本文来自于对好雨云创始人刘凡的专访,他给我们详细介绍了微服务在好雨云的实践。

  微服务架构成功的因素

  微服务的众多优势让其成为当前受到众多厂商和开发者的热捧, 据刘凡介绍,好雨云平台在打造之初并没有为了实施微服务而实施微服务,其实,微服务本质上是好雨云平台的一个非常核心的功能,简而言之,用户只要在他们平台上部署服务,它本身就是个微服务,实际上好雨云整个平台的核心就是基于微服务的架构去搭建的,所以用户不管部署的是程序还是部署传统服务,或者一个其他的第三方应用程序,在这中间都可以按照微服务的方式进行。

  另外,刘凡表示当前对于微服务来说,最大的一个挑战就是当服务特别多的时候,对于大量服务的管理仍然是一个不小的挑战,而好雨云从整个服务的部署、伸缩、高可用、容错、监控以及服务之间一个依赖关系都给出了自己的解决方案。

  值得一提的是,目前国外很多的互联网巨头包括Google、Netflix、Facebook、Twiter等在微服务实施领域都取得了成功,给国内想要进行微服务实施的企业提供了有益的借鉴。在刘凡看来,微服务要实施成功关键在于以下几个方面:

  第一,这些巨头根据自己的业务特性,研发适合自己的微服务框架。 第二,在经过长期的实践,对业务重新建模,合理的将业务拆解成微服务。 第三,当微服务的数量增多,为保证服务可用性,需要有可靠的容错机制。 第四,依赖公有云或自建云服务,满足互联网模式下的快速业务伸缩。

  微服务的本质是管理

  谈及国内的微服务情况,刘凡认为当前国内的微服务实践大多数都还是个概念,实际上很多企业的业务还是一体化架构,在从一体化架构向微服务转变过程中,国内企业首先需要做的事情就是对业务进行拆解,合理的模块化业务;其次,需要优化整个服务管理。针对上述两个问题,他指出,对于希望实施微服务架构的企业来说,首先还是要从梳理自己的业务架构开始,逐步的把一体化架构拆解成微服务化架构;不能为了实施微服务架构而实施微服务架构,需要清晰的认识SOA架构跟微服务架构的差异,真正的有效的去实施微服务架构;最后,要擅于利用工具为实施微服务提供支持,如果可以有效的利用工具,对于提升整个公司微服务的实施效率有很大帮助。

  虽然微服务具备很多的优势,但是由于微服务本身的特性,实施起来的的难度非常大,那么对于国内企业来说真正愿意实施微服务的意愿有多大,刘凡表示,在当前企业架构里面,服务的部署、伸缩、高可用、容错、监控等,本质上,是对现有服务的管理。如果不谈微服务架构,如果只是有微服务架构管理工具支持,照样能极大提升运维和开发效率,这属于低层次的价值;而对于高层次来说,微服务架构能解决CTO的管理问题,合理的微服务抽象和拆分对应合理的组织结构划分, 每个服务就变成一个独立的小产品,运营这个产品就是组织主要目标,产品的价值决定组织的价值,产品用户的多少决定组织价值的高低,这种市场化的管理方法是最简单有效的管理方法。 另外,微服务架构能帮助技术团队快速开发和迭代产品,对创造一个成功产品有很大帮助。

  微服务在好雨云的解决方案

  

图片描述

  好雨云平台的底层是通过Docker实现的,只是用户感受不到Docker。通过这种内部封装,用户不用管理计算资源和网络资源,把复杂技术包装在内部。通过服务整体对外。

  

图片描述

  只要提供代码就能一键部署在各种环境。 开发语言支持Java、Python、PHP、Ruby、Golang,Node.JS等,代码仓库支持Github,好雨托管仓库。

  

图片描述

  垂直伸缩只需要设置资源的大小,水平伸缩只需要设置节点的个数。

  

图片描述

  通过高可用调度器,所有服务都具备了高可用特性。

  

图片描述

  类似Spring的依赖注入,要调整服务的依赖关系只需要界面点击久能轻松完成。

  

图片描述

  类似保险丝,当服务B变慢,达到断路器的阀值,服务B将自动下线,不至于影响其他服务,当延迟变小,服务逐步恢复。

  

图片描述

  业务指标:平均响应时间,吞吐率 ,在线人数。在实际场景中,使用业务监控可以替代技术监控,而且更加简单容易理解。

  Docker的出现将简化微服务的管理

  对于当前Docker的火热,刘凡表示,Docker的出现第一让部署更加快捷,第二,统一打包方式之后,对于整个微服务的管理更加简化。

【案例分析】

开发人眼中的微服务架构云端应用

摘要: 拥有超过12年互联网产品开发和管理经验,好雨云创始人兼CEO刘凡对微服务架构云端应用的干货分享。

微服务架构很热,讨论的文章非常多。但如果提到微服务架构的云端应用,可以深入分析的还比较少。本篇来自中生代技术群(FreshmanTechnology)第二期,好雨云创始人兼CEO刘凡的分享。其曾任澳客网 CTO和CEO职位。拥有超过12年互联网产品开发和管理经验,专注于互联网技术架构设计,对产品设计、敏捷开发、安全、OKRs、大数据等领域有深入研究。现推崇反应式编程(http://www.reactivemanifesto.org/),并在多个产品中成功应用。


下为正文:



微服务架构(Microservices Architecture)是一种架构风格和设计模式,提供将应用分割成一系列细小的服务,每个服务专注于单一业务功能,运行于独立的进程中,服务之间边界清晰,采用轻量级通信机制相互沟通、配合来实现完整的应用,满足业务和用户的需求。


微服务的优点:

  •     可独立部署、升级、替换、伸缩
  •     自由选择开发语言
  •     高效利用资源
  •     故障隔离


总结下来就是:灵活、稳定、省资源。

微服务的缺点:

  •     服务多,带来更多操作
  •     管理复杂度提升
  •     部署难度加大


总结就是:服务多,管理难度大。

仅管微服务存在着缺点,但它的优点也是非常吸引人的,目前很多企业也逐渐开始了微服务架构之旅,包括像Twitter,Netflix,Amazon,eBay等大厂商都在使用。如下图是Twitter微服务应用部分架构图。


ebcce4f5a869bb0e59940038b8e1a8a034f08db8

微服务的架构模式


1. 一体化架构模式

6740e4e6e9accb1cee4e0fd38e3207698674b4ba

传统mvc架构,也是一体化模式。


2. 聚合模式

680d0d2ed4d33c553deda95e1ff69b40ea4051ce

从多个服务的结果聚合到一个聚合服务,最常见的表现是聚合服务是Web服务,主要功能是页面表现,后端的服务都是纯业务功能服务,扩展业务只需要增加一个新的后端微服务就可以啦。

聚合服务也可以是一个更高层次的组合微服务,增加业务逻辑后进一步发布成一个新的微服务,这符合DRY原则。另外,每个服务都有自己的缓存和数据库。这个模式是最常用模式。

3. 代理模式

a075a91b4b0628602f13013ef8d4115ea6b6416d

4. 资源共享模式

aea2cbfd83ecf6e07d2f1e4e722b4992f36f9703

可实现部分业务的逻辑分离,数据共享。

用在一体化架构往微服务架构迁移过程中的过度状态。还可用在两个服务之前有数据一致性要求,通过统一的数据库事物来实现。

5. 异步消息模式

372e961f3073b40c6b18a361ee3a37b1d0e37af3

上面的其它模式都是同步的,会阻塞。异步消息模式适合不需要同步的场景,比如任务型服务。

主要的模式就这些,其它模式可以由这些模式演变。

大量微服务带来的挑战


1. 服务部署的挑战


每个服务都需要独立的代码管理、版本管理、编译构建、部署到测试环境,部署到生产环境,代码回滚等等事情,如果要有几十个服务要部署,人工管理几乎不可能完成。

2. 服务绅缩的挑战


无状态服务需要配置负载均衡和增加节点,有状态服务需要扩充单个服务的资源,如果需要减少资源浪费,需要监控每个服务,还需要减少节点和资源。

3. 服务高可用的挑战


每种服务的高可用策略都不一样,无状态服务相对简单,管理每个有状态服务都是难题。

4. 服务容错的挑战


任何一个服务的可用性都不是 100% 的。在分布式系统中,当我依赖的某个服务不可用的时候,我自身也将不能工作。如果是一个复杂的分布式系统,会依赖更多服务,任何一个服务不可用的时候,系统自身也将不能工作,再加上网络不稳定的因素,系统自身的可用性将大幅度下降。

5. 依赖关系的挑战


依赖配置文件,如果写在代码中,需要重新部署才能生效,而配置文件还会污染代码。

6. 服务监控的挑战


监控cpu?负载?大量微服务如何同时监控?


微服务在云端的解决方案

底层是通过docker实现的,只是用户感受不到docker。

内部封装,不用管理计算资源和网络资源,并把某些复杂特性包装在内部。整体对外,服务做为一个整体管理。

3704538f69485946bf1d398b975a5d34836cbdd2

开发语言支持Java、Python、PHP、Ruby、Golang,Node.JS等,代码支持Github,好雨托管仓库。

700e9e26d785add6e554c33ab518cb1b9d333c62

水平伸缩用于无状态的 Server和Worker 类的服务。

垂直伸缩用于有状态的服务。


部分有状态服务支持水平分区( sharding),用户只需要调整节点个数就可以了。


01d51e15e2bb3769743973142d1054776a41cc74

一般通过LB支持无状态服务高可用,支持有状态服务高可用。

8f7a71560e9f8dc9a8e716df0fe9a2c5eeed431d

类似Spring,参数通过环境变量实现。

实现微服务之间的连接和编排,以上微服务模式都可以通过这种方式动态配置实现。

4ddc3ff86bb05e052dc4367ce3c1e484cdaa5865

类似保险丝,当服务B变慢,达到断路器的阀值,服务B,将自动下线,不至于影响其他服务,当延迟变小,服务逐步恢复。容错还有一种方式是使用异步,可以参考CQRS模式。

915955bbf2ac003c1e77787190018c9f48439e9b

业务指标:平均响应时间,吞吐率 ,在线人数。

在实际场景中,使用业务监控可以替代技术监控,而且更加简单容易理解。


b5b8e2cff71b21ee64c8f4a46004a47d69a9fc760cf2a1a5df098fb0b34d7159f1afd41768bb6302

单个REST服务的实时性能分析,数据库性能分析,最慢的Sql语句不一定是对数据库影响最大的。实时性能分析通过CEP+log实现,以前工作一直使用,没有APM炫,但解决了很多实际问题。还在实现了Mongodb ,Redis等数据存储的实时性能分析。

至此,相信你也对微服务,微服务的构架模式以及微服务在现实场景中的应用有了一个大概的认识了。如果你还想要了解得更多,请继续查看下面的Q&A环节内容。



Q&A


Q1 99.95%的SLA是如何测量的,现在都有那些初始客户? 

刘凡: 我们自己实现了负载均衡组件,监控每个租户的服务可用性,后端服务不可用和错误返回码都会算到不可以用时间。我们现在的用户有工行,天津滨海新区管委会,章鱼网,51talk,学霸君,好贷宝等。

Q2 依赖调整配置就生效吗,背后是如何做到的? 

刘凡: 我们的服务发现是通过etcd实现的,之前实现了完全实时修改实时生效的方案,但是太复杂了,现在的实现方式是通过环境变量实现的,修改配置之后需要重启,无状态服务用户感知不到。 

Q3 SOA的时候重点谈到了美好的编排,不同粒度的层次,逐层编排,其实最考验设计能力和抽象能力,编排本身的美好得不到很好的利用,如何破?


刘凡: 这只能考验一个公司的技术架构师和业务架构师了,我以前身兼这两职,我没遇到过这些问题。我也没有其它思路。


Q4 监控部分对于内存泄漏,堆栈分析有没有好的支持? 

刘凡: 这个没有,但是如果由于内存泄漏导致服务死掉,我们平台会自动重启。

Q5 你们云平台本身有没有异地容灾的能力?  

刘凡: 我们能实现geo-master,现在设计如何对用户开放这类服务。

Q6 微服务这块在移动端有没有好的案例,一般像Android和 iOS这类移动应用上如何使用和借鉴微服务模式呢?

刘凡: 刚才分享的代理模式特别适合用户移动开发场景,微服务都是API。代理模式是一种特殊的聚合模式,对外是一个统一的包装,一般做内部接口的代理,对外统一一个接口,内部可以用多个微服务实现。

Q7 服务之间有没有调用链的设计,方便跟踪跨服务的问题,可以分享一下吗?

刘凡: 细化的跟踪没有,通过服务拓扑可以实现粗力度的。

Q8 工行上的是那些业务,好雨云擅长是高性能高PV的业务,还是对事务一致性要求都有很高要求的业务?

刘凡: 高PV场景我们特别适合,因为我们非常容易伸缩。事务一致性我们有两种方式,一种大家可以选择自己喜欢的存储服务,各类数据有存储自己的方式。第二种,我们通过akka实现一套高一致性,高性能的解决方案,单机能做到每秒100万的事务。

Q9 你提到了类似在线人数之类的业务监控,对于产品可以增强链路监控功能否,比A9如用户是在操作链路上那个环节流失得比较严重,做统计以便产品改进,这些监控本身需要调用平台API吗?

刘凡: 不太理解链路是什么意思,是指用户行为数据吗?现在我们没有,我们不擅长这块。

Q10 服务拓扑就是服务级依赖关系吧?

刘凡: 是的,每个微服务有自己的响应时间和吞吐率,表现在拓扑图里,可以粗力度分析出问题。

Q11 我们通过akka实现一套高一致性,高性能的解决方案,单机能做到每秒100万的事务,这块能不能具体说一下,比如一个第三方支付简单的A用户到B用户的转账场景,A和B在不同的sharding单元。

刘凡: akka的模式是使用CQRS模式,也就是事件溯源的方式,以前数据库的那些事务问题在这都不存在。

Q12 Akka的话是不走数据库直接在内存里做事务吗?

刘凡: 是的,通过事件溯源保证数据一致性。理论上它不是事务,但能实现事务的效果。

Q13 队列技术如何支持的呢?

刘凡: 我们平台支持任何开源的队列服务。

Q14 微服务之间如何通信,协议和数据格式是怎样的?

刘凡: 微服务会有多个节点,但我们会内置LB,对外统一一个服务接口,支持任意协议和格式。

Q15 工行,天津滨海新区管委会,章鱼网,51talk,学霸君,好贷宝主要应用场景,高PV支持,高事务支持,大数据分析,爬虫,devops,通过微服务架构把业务能拆分更小,便于重用和维护。 akka的方案就是联机交易。这些客户具体的应用场景是哪些呢?可以选择1-2个典型case介绍下微服务所产生的价值,如果有联机交易的Case更佳。

刘凡: 介绍下微服务所产生的价值,如果有联机交易的Case更佳主要应用场景,高PV支持,高事务支持,大数据分析,爬虫,devops,通过微服务架构把业务能拆分更小,便于重用和维护。 akka的方案就是联机交易。

Q16 实时性能分析用的是cep +log, 不是很理解cep?

刘凡: 复杂事件处理,实时流处理,通过strom也可以实现。

Q17 如何应对微服务的毛剌现象(某个服务瞬间出现较大延迟的现象,可能会导致某批请求超时等情况)?

刘凡: 不好意思,我没遇到过这种情况,我觉得应该跟实现方式有关。

Q18 akka的方案就是联机交易,akka原先架构体系是什么?遇到了什么样的瓶颈?微服务之后改进的是什么?联机交易规模怎样?

刘凡: 原先就是用传统数据库,交易的事务性能低下,做了sharding会引入新的问题,而且联机分析也有问题,用akka改造后能处理高峰业务每秒10万左右的事务。


                                                            中生代技术分享群微信公众号

                                                         da9312524921e637b684eed7bf3249db58f7badc


展开阅读全文

没有更多推荐了,返回首页