专访宜信梁鑫回归架构本质重新理解微服务

本期专访宜信开发平台（SIA）负责人梁鑫，与大家一起聊聊微服务架构及其在企业落地应用的策略。

第一部分：微服务的诞生、演变以及应用策略

记者：近几年来，微服务架构设计方式被提出并在越来越多的企业中得以实践和落地，但对于刚开始接触微服务的人来说，还是不知道要从哪些方面开始了解。您能否结合软件架构的发展历史，聊聊微服务的发展与特征。

梁鑫：微服务本质上是一种架构的风格，如果要了解微服务，我认为需要先了解整个架构的发展脉络。

软件架构，总是在不断的演进中。如果把时间退回到二十年前，当时企业级领域研发主要推崇的还是 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…

记者：微服务任务调度平台（SIA-TASK）适用于哪些场景?

梁鑫：SIA-TASK 是基于 HTTP 协议的进行远程调度的，实际业务中高并发的调度处理支持肯定是不够理想的。如果业务是高并发的、每秒钟需要唤醒几千几万个任务的场景就不太适合使用 SIA-TASK。除此之外，其他所有场景几乎都可使用 SIA-TASK。