第一部分:微服务的诞生、演变以及应用策略前端
记者:近几年来,微服务架构设计方式被提出并在愈来愈多的企业中得以实践和落地,但对于刚开始接触微服务的人来讲,仍是不知道要从哪些方面开始了解。您可否结合软件架构的发展历史,聊聊微服务的发展与特征。git
梁鑫:微服务本质上是一种架构的风格,若是要了解微服务,我认为须要先了解整个架构的发展脉络。github
软件架构,老是在不断的演进中。若是把时间退回到二十年前,当时企业级领域研发主要推崇的仍是C/S模式,PB、Delphi这样的开发软件是企业应用开发的主流。数据库
随着时间的推移,咱们发现标准化的客户端存在一些弊病,好比我有一千个终端,升级版本须要每一台终端都升级,这是很是麻烦的。而后,企业应用研发开始向互联网学习,把浏览器做为客户端来使用,就能够避免这个问题。所以,基于浏览器的B/S架构开始渐渐流行起来。编程
刚开始的时候是ASP,以后又出现了JSP,由于Java的预编译模式,让性能有了很是大的提高,随后基于Java语言的J2EE架构就变得愈来愈流行。至此,架构经历了从传统的C/S模式到B/S模式的转变。浏览器
B/S架构初期基本都是单体架构,各个系统比较独立,他们之间每每不须要进行交互,即便存在一些交互,也大可能是数据层面的。那个阶段ETL工具发展得很快,就是为了解决这样的数据孤岛问题。架构
随着企业应用愈来愈多,系统之间相互的关系也愈来愈密切,系统之间实时交互访问的需求也愈来愈多。这个时候工程师们发现,无论是什么语言开发的软件,基本都支持一种叫作XML的语言,因而提出一种实时交互的技术解决方案:经过XML语言来进行企业应用系统之间的远程调用。由此,SOA的概念被提了出来,WebService开始流行。并发
当第二波互联网浪潮来临后,不少公司为了适应更加灵活的业务发展,用基于HTTP协议和Restful的架构风格替代了原先笨重的WebService,简洁清晰的JSON替代了XML。同时SOA架构中经常采用服务总线技术,无疑是给系统架构增长了一个异常麻烦的瓶颈。若是使用注册和发现的机制,让服务进程之间直接进行调用,更适合企业应用的发展。这就是微服务架构从技术方面来讲的历史脉络。框架
在《微服务设计》中界定微服务有两个基本原则:松耦合&高内聚。即“把因相同因素变化的事情汇集在一块儿,把因不一样因素变化的事情区隔开来。”至于微服务大小的划分并无统一的标准,通俗地说,就是你以为它的大小差很少,同时符合“松耦合&高内聚”的原则就能够。运维
微服务有不少的好处,大体列举一些。
- 异构:微服务能够帮助咱们轻松采用不一样的技术,而且理解这些新技术的好处。尝试新技术一般伴随着风险,但若是把服务切得很小了,总会存在一些点让你能够选择一个风险最小的服务采用新技术,并下降风险。
- 弹性:很明显,微服务能够很好地处理服务不可用和功能降级的问题,由于它能够造成不少个节点。
- 隔离:微服务架构将系统分解为独立运行单元,给系统带来更好的隔离性,独立的微服务在发生异常时更容易定位和隔离问题,隔离性也是服务扩展性的基础。
- 扩展:庞大的单体服务只能做为一个总体进行扩展,即便系统中只有一小部分模块存在性能问题,也须要对整个系统进行扩展。而微服务架构能够根据性能须要对不一样的模块进行水平扩展。
- 部署简单:在微服务架构中,各个服务的部署是独立的,这样就能够更快地对特定部分的代码进行部署。服务出现问题也更容易快速回滚,同时敏捷的交付和部署带来了更好的业务需求响应体验。
- 灵活:在微服务架构中,系统会开放不少接口供外部使用,当状况发生改变时,可使用不一样的方式构建应用。把单体应用分解成多个微服务,能够达到可复用、可组合的目的。
记者:据悉,您以前发表过一篇文章“公司为何须要创建一套统一的开发框架?”,您认为公司创建统一开发框架是为了解决什么问题?
梁鑫:这是一个仁者见仁智者见智的问题,每一个人的出发点都不同,有的人可能主张须要统一,有的人则可能排斥统一,结合个人经历和实践来看,我认为公司是须要创建统一开发框架的。
近十年,互联网的发展颠覆了不少传统行业,不少新兴公司如雨后春笋般的冒了出来,它们的业务增加很是快,公司规模也愈来愈大。这得益于中国经济的高速增加和互联网的快速发展。但这种高速的发展过程当中伴随而来的是不可忽视的弊端:
- 弊端一:自我繁衍
在公司快速的发展过程当中,每每会出现这样一个链条。新增一块业务 —> 招聘一位高级技术人员 —> 围绕这位同事组建一支技术团队 —> 该业务基本由这只团队负责,而后就造成了一个闭环。当须要跟其余业务进行交互时,常常是技术负责人之间自行决定。这就造成了自我繁衍的状态。
- 弊端二:管控壁垒
随着业务规模的快速发展,这个团队很快造成了一个部门,团队决策者一般会从自身利益考量,但愿尽可能减小对外部门的依赖,不管是技术选型、规范创建、组件选取、运行环境都可以自行掌控。
- 弊端三:断崖效应
当这样的技术氛围一旦造成,单个员工对单个项目的影响就会变的很是巨大。一个产品常常会由于一两个核心员工的离职难觉得继,最后不得不从新开发新的产品。
- 弊端四:资源浪费
当每一个团队都在试图构建本身完整的研发流程时。中间的技术研究、产品研发、运维管理就会出现很是多的资源浪费。
- 弊端五:难以考核
怎么衡量一个川菜厨师和一个鲁菜厨师谁更优秀?当每一个团队都是一个闭环,采用不一样技术栈、不一样的技术组件、不一样的维护方式和规范时,已经没法从产出效率来判断一个团队的绩效,KPI 指标也就很是难以设立。
创建一套公司级的统一的开发平台能够有效解决上述问题。从技术层面来说,若是能够造成公司级别的统一开发平台,会在实际的生产过程当中带来很是大的收益。
- 首先,避免了重复性技术研究,节约了人力成本。在项目组之下构建一个基础的开发架构平台,把技术共性问题提炼出来,交给一个专门团队负责处理,让项目组把精力投入到业务中。
- 其次,标准化了技术规范,提高了产品项目质量。作工程要千人一面,而不要千人千面。采用统一的开发平台后,在技术栈、技术组件、技术实现方案,甚至在代码规范上,就能造成标准化的技术输出模式,标准化带来的效果不只仅是开发效率的快速提高,还有产品质量的大幅提高。
- 再次,能够进行技术沉淀,提高公司总体的技术能力,避免陷入一我的的能力决定一个项目。技术的进步来源于不断的技术积累和沉淀,创建公司级别的统一开发框架(平台),项目团队基于该平台进行自身项目的研发,再也不须要关注于底层技术实现,只须要关注业务便可。并且,专一于平台的同事为了更好地知足项目组的技术需求,对平台进行不断的改进,从而达到技术积累和沉淀的目标。
- 最后,能够对研发的投入和产出进行衡量,对研发团队进行有效管理和考核。当基于同一开发平台的标准化技术规范创建起来后,对业务功能的代码实现就能够进行相对有效的评估和考量,能够避免由于技术实现差别而出现的种种问题。这对KPI的制定和考核是一个巨大的帮助。
我从前年提出这样的一个思想,经过一年多的努力,已经在公司有了必定的成果。咱们的统一开发平台定位于技术层面,其主要目的是为统一公司内相关产品研发和项目实施使用的技术架构和开发工具,有效提升统一技术支持力度,造成持续的技术积累手段,提高技术人员的利用率并下降对人员的依赖性,最终提高软件的规模化、流水线式的生产能力。
记者:最近“Spring Boot”、“Spring Cloud”等词总被说起,这些新的框架集合方案与传统的微服务框架相比有哪些优点?结合您的经验来看,您认为微服务将来的发展走向多是什么?
梁鑫:我是公司内部较早研究Spring Cloud 技术栈的人,也是Spring Cloud中国社区的成员。Spring Cloud是在2017年一跃成为最流行的微服务开发框架。可是,这里有一个须要辩证看待的问题。“不是说使用了Spring Cloud框架就实现了微服务架构,具有了微服务架构的优点”,正确的理解应该是“使用Spring Cloud框架开发微服务架构系统,使系统具有微服务架构的优点。”
Spring Cloud之因此能从其余框架中脱颖而出成为最火的框架,得益于其自己体系的完整性。这一点经过下图Spring Cloud、Dubbo和ServiceComb的对比能够比较直观地了解到。
另外,Spring在中国有普遍的群众基础,我也比较推崇这种“约定大于配置”的研发思想,不须要彻底依赖标准化的东西。
我不敢妄谈微服务架构的将来走向。立足当下,我认为目前Spring Cloud+Docker容器化的技术是用于微服务架构的一个比较好的选择。我比较承认一个颇有趣的说法是“基因架构”,意思是:架构从诞生之初就是为了改变的,因此你的架构越容易改变就越好。我以为架构的将来会向这条路发展。
咱们的统一开发平台的建设就是基于Spring Cloud技术栈。
记者:今年在软件研发行业比较热门的话题是“中台”,在架构层面也有人提出来要作微服务中台,对此您怎么看?
梁鑫:去年一个综艺节目带火了一句话,“盘它”。节目里有一句 “干干巴巴的,麻麻赖赖的,一点都不圆润,盘他!”。 后来讲到什么就盘什么,也无论是什么东西,能不能握在手中,反正盘就是了。听起来是否是特别有魔性,而后就有了“万物皆可盘”这个段子。这自己其实只是一种调侃的讲法,也并不会真的有人看到什么就盘什么。有意思的是任何事情均可以再认真往深处想想,你会不会也犯一些看似荒唐的错误呢?
今年技术圈最火的一个名词就是“中台”,套用到这儿就变成了“万物皆可中台”,一个名词处处套,我认为不少公司应该避免盲目跟风,让“中台”成为名词陷阱。
面对一个新的技术或趋势,咱们要先了解其来源和根本。中台的来源须要回溯到阿里。2015年阿里巴巴集团启动了中台战略,目标是要构建符合互联网大数据时代的,具备创新性、灵活性的‘大中台、小前台’的机制,即做为前台的一线业务会更敏捷、更快速地适用瞬息万变的市场,而中台将集合整个集团的运营数据能力、产品技术能力,对各前台业务造成强有力的支撑.
那阿里集团为何要创建一个‘大中台、小前台’的架构呢?《企业IT架构转型之道——阿里巴巴中台战略思考与架构实战》一书对此有详细介绍。从阿里共享业务事业部的发展史提及,起初,阿里只有一个淘宝事业部,后来成立了天猫事业部,此时淘宝的技术团队同时支撑着这两个事业部。当时的淘宝和天猫的电商系统像咱们不少大型企业的同样是分为两套独立的烟囱式体系,两套体系中都包含的有商品、交易、支付、评价、物流等功能。由于上述缘由,阿里集团又成立了共享业务事业部,其成员主要来自以前的淘宝技术团队,同时将两套电商业务作了梳理和沉淀,将两个平台中公共的、通用的业务功能沉淀到共享事业部,避免重复建设和维护。
做为一个拥有10多年编程经验的老兵,我常常思考的一个问题就是系统发展的规律,透过其形领会其意,回顾架构的发展,我认为能够总结出一点:“快”。固然这个快是有前提的,好比正确率、资源限制,要在稳定、尽可能减小资源消耗的状况下求快。
“快”能够再次分解,从开发的角度来看,编写代码要快、开发要快、功能测试要快、环境部署要快、服务启停要快;从生产的角度来看,程序运行的速度要快、高并发之下仍是要快等。
微服务架构之因此流行,由于把服务拆小了,能够高度复用,不用常常编写和修改代码,节省了很是多的时间;容器化技术之因此流行,由于容器化技术可使得生产环境和测试环境一致,节省了大量的环境部署时间、减小了出错的可能性,还能够随意增长容器节点,加强业务处理能力,保证高并发下的快速响应。分布式架构也是如此,微服务架构其实就是分布式架构的一种演化。万变不离其宗,都是追求“快”。
回到“中台”这个话题,建设中台的目标是避免重复建设和维护,快速响应需求。后台和平台的系统比较稳定,通常不轻易发生变化,并且从稳定性考虑,应该尽可能减小后台和平台系统更新的次数,前端系统由于要适用用户的需求而不断变化,这样前台和后台在对接时就产生了一个求变一个求不变的矛盾,这时咱们但愿在二者之间创建一个中间平台,把前端后台可重复利用的东西集中到这个中间平台来,从新封装组合对外提供服务,这是符合“快”的思想的。
这是中台的来源和根本,企业在建设中台以前,必定要先了解这些,看所要建设的中台是否符合“避免重复建设和维护”的思想,是否符合“快”的原则。
第二部分:微服务在业务中的应用须要解决的关键问题
记者:宜信在今年开源了微服务任务调度平台SIA-TASK,这个平台在宜信技术团队内部有普遍的应用,开源后也获得了不少开发者的支持。您可否介绍一下这个平台的设计思路以及核心功能?(设计开发这个平台想要解决什么问题)
梁鑫:前面谈到中台,其实我认为“中台”只是一个名称而已,只要符合“避免重复建设和维护”和“快”两个原则,叫什么均可以,好比咱们的微服务调度平台SIA-TASK,就是一个很像中台的系统。
介绍SIA-TASK的设计思想以前,我先介绍一下它的背景。不管是互联网应用或者企业级应用,都充斥着大量的批处理任务。经常须要一些任务调度系统帮助开发者解决问题。随着微服务化架构的逐步演进,单体架构逐渐演变为分布式、微服务架构。不少原先的任务调度平台已经不能知足业务系统的需求,因而出现了一些基于分布式的任务调度平台。这些平台各有其特色,也各有不足之处,好比不支持任务编排、与业务高耦合、不支持跨平台等问题,不符合新一代微服务架构的需求,所以咱们开发了微服务任务调度平台(SIA-TASK)。
SIA-TASK 使用 SpringBoot 体系做为架构选型,基于Quartz及Zookeeper进行二次开发,支持相应的特性功能,SIA-TASK 的逻辑架构图以下图所示:
SIA-TASK是任务调度平台的一站式解决方案,契合当前微服务架构模式,具备跨平台,可编排,高可用,无侵入,一致性,异步并行,动态扩展,实时监控等特色。
了解任务调度平台,须要先了解任务调度。任务大体分为三种,按期执行的任务;隔固定时间执行但不可并发的任务;每隔固定时间执行的可是能够并发的任务。任务之间还可能存在一些次序关系,好比:串行、并行、分支等。
当咱们进行任务调度的时候,经常会发生如下的一些问题。
- 遗忘,一个项目有跑批任务,项目下线后跑批流程还在继续,直到产生的日志把磁盘空间占满了才发现;
- 单点,某个项目的跑批流程一直单点,机器故障后,流程中止运行;
- 依赖,某个项目的跑批流程A和B有依赖关系,只能设置两个任务的时间错开,若是发生A延时,须要手工处理出错数据。
咱们在设计SIA-TASK的时候,将平台和项目组运行割裂开来。SIA-TASK包括五大模块,任务执行器,即真正业务逻辑须要跑批的业务,属于项目组,项目组在启动的时候会把执行的任务暴露成一个服务,这个服务注册到任务注册中心来;任务注册中心拿到一个任务,并将它存储到持久存储的数据库里,同时进行编排,编排成有依赖关系的任务;最后任务调度中心拿到任务编排中内心已经编排好的须要执行的任务,进行远程调用。
在整个过程当中,任务调度、编排、执行与项目组是分开的,项目组只须要关心任务调度的业务逻辑代码,剩下的都在SIA-TASK平台执行,至关于把每一个项目任务都原子化了,都变成了一个个微服务。
只把业务逻辑留在项目组,调度、编排、执行归类到平台中,全部须要代码处理的东西都经过配置化的方式实现,也符合中台“避免重复建设的维护”的思想。
SIA-TASK目前已经开源,具体的设计思想和功能以及部署操做能够在GitHub查看,地址: https://github.com/siaorg/sia-task
记者:微服务任务调度平台(SIA-TASK)适用于哪些场景?
梁鑫:SIA-TASK是基于HTTP协议的进行远程调度的,实际业务中高并发的调度处理支持确定是不够理想的。若是业务是高并发的、每秒钟须要唤醒几千几万个任务的场景就不太适合使用SIA-TASK。除此以外,其余全部场景几乎均可使用SIA-TASK。
来源:宜信技术学院