从微服务跨越到中台，架构领域年度盘点！

互联网架构师 2020-10-08

作者 | 小智、薛梁

来源丨订阅号 InfoQ

2019 年，整个 IT 领域发生了许多深刻而又复杂的变化，InfoQ 策划了“解读 2019”年终技术盘点系列文章，希望能够给读者清晰地梳理出 IT 领域技术这一年的发展变化，回顾过去，继续前行。

背景在过去的十年时间里，软件开发的各个领域里发生了巨大的变化。云计算从虚拟机到容器再到云原生；数据库从关系型到 NoSQL 再到 NewSQL；运维从手工运维到 DevOps、AIOps……而在相对稳定的架构领域，也经历了从单体应用到 SOA 再到微服务的演化过程。在固有印象里，软件开发领域更新换代最快的当属前端领域，“别更新了，学不动了”、“前端领域十八个月难度翻一番”，这是前端开发们的自嘲。但在过去的一年中，相对稳定的架构领域同样发生了巨大的变更，所谓中台、云原生带来的云时代架构，这些对企业技术架构带来了深切的影响。过去几年间，上云成了互联网企业的主旋律，而到今年，该上云的互联网企业基本都已经完成了上云步骤，传统企业也在评估着单云多云混合云的部署方案。全面云计算时代已经来临，与之相匹配的云时代的架构又该是怎样的呢？本文试图梳理过去一年时间里，架构领域发生的种种变化，为读者揭示一个软件架构过去与未来的全貌。中台2019 年可以称得上是中台元年，这一年如雨后春笋般涌现的中台名词不胜枚举，业务中台、数据中台、技术中台、算法中台、AI 中台等等让人目不暇接。一般而言，互联网企业的“中台”战略由阿里巴巴首先提出，但中台的思想其实在银行业、硅谷等都有落地经验。阿里的中台是个累积的过程，从 2009 年建立共享事业部开始，几经曲折，但是一直在积累，直到 2015 年正式发展成中台战略。阿里目前的中台大约有十几个共享业务单元，包括用户中心、商品中心、交易中心等。淘宝、天猫、聚划算等 25 个大型业务应用都是由中台的共享业务单元支持的，共享业务单元则由阿里云平台支持。

谢纯良《阿里巴巴中台技术架构实践与思考》

无独有偶，硅谷虽然没有“中台”一词，但类似的中台建设实践早已有之。此前亚马逊 CTO Werner Vogels 在总结亚马逊过去多年的软件开发经验时曾提到：

为了支持这种新型架构，我们分解了功能层级结构，并将企业组织重新编排为小型自治团队——小到每次点餐只需要两份披萨。我们将这些“双披萨团队”委派到不同的特定产品、服务或者功能集上，赋予他们对应用程序内特定部分的更多操作权限。这使得我们的开发人员成为产品所有者，并能够根据自己的决策迅速对个别产品产生影响。

互联网一直以来的特点就是赢家通吃，只要成功企业推出的前沿概念，盲目追随者的数量不在少数。阿里巴巴在业务和技术上的成功让“中台”一词被业界奉为圭臬，好似软件开发领域的又一颗银弹。但软件开发的历史规律告诉我们，软件开发没有银弹，有的只是与时俱进、不断迭代的 IT 架构。

中台出现的历史背景有很多，但对企业级 IT 而言，解决业务架构的痛点永远会是其中一个重要原因。

业务架构业务架构是一个存在二十多年的概念，很多工程师认为业务架构与技术架构相比，缺乏技术含量，对于工程师的能力增长没有多少帮助。但对于大型科技公司而言，业务架构却非常重要。它是连接企业战略和技术实现的桥梁，是连接业务人员与技术人员的桥梁。基础架构有很多可以复用的通用能力，但业务架构却是千变万化需要针对企业自身业务去设计、生长的。2011 年，Gartner 发布的报告中不无担心地提到：只有 9% 的企业架构活动是在组织内业务方面的合作下完成的。虽然合作项目的比例有望在 2016 年提高到 30%，有人认为企业架构小组参与度这样低还是让人警觉，也使他们处于被业务团队抛开而独自做出技术决策的风险之中。9 年过去了，新的观点认为，未来每家公司都是科技公司。传统行业，更多开始将自身业务与新兴科技相结合，而在零售、餐饮、出租车等领域，运用的技术直接造就了各大电商、美团、滴滴等科技公司。在当前的云时代下，业务架构将变得更加纯粹专注、聚焦在业务上。云时代以前，业务架构要大包大揽，什么都自己做，但在云时代下很多基础的事情可以交给云来做。除了云计算给业务架构带来的改变，中台概念的出现也对业务架构的设计产生了很大影响。一般来说多个业务能够复用的技术能力，应该放在中台来建设，业务架构直接复用就行，不用重复造轮子。微服务成了连接业务架构和中台的一个桥梁。微服务这些年里，软件架构逐渐从 SOA 进化到微服务，很多人认为微服务是一种细粒度的 SOA，在去掉了 SOA 中的 ESB 之后，微服务变得更加灵活、性能更强。Martin Fowler 曾经总结过微服务实施的前提包括：计算资源的快速分配、基本的监控、快速部署。这基本就是 Kubernetes 所起到的主要作用，随着云原生计算基金会的壮大，基于 Kubernetes 的微服务在社区中的热度越来越高，也开始有很多公司开始利用这一套技术栈来构建微服务。伴随着微服务转型的浪潮，一个名叫 Service Mesh 的技术走上了微服务的舞台。2016 年，由开发了 Linkerd 的 Buoyant 公司提出。Service Mesh 的出现，极大地补充了 Kubernetes 生态的微服务选型，再加上 CNCF 的一些开源项目，基于 k8s 的微服务技术栈基本就完善了。2018 年 Istio 1.0 发布，更是为这股浪潮加了一把火，未来的微服务将是 Kubernetes 和 Service Mesh 的天下。凭借着 Kubernetes 和 Service Mesh 的双剑合并，微服务逐渐走向了巅峰，但此时它的挑战者 Serverless 已经出现。Serverless 或者说 FaaS 最开始只是 AWS 推出的一个功能，但现在业界已经有人将其看作微服务的进化，因为其内含的 Function 可以视为更小的、原子化的服务，天然地契合微服务的一些理念。

（许晓斌《从微服务到 FaaS》）

但目前而言，Serverless 即便在阿里、腾讯等大公司，也仍旧是一个摸索状态，如何将其融入现有架构业界尚没有成熟的经验，也没有太多落地案例，其自身也存在一些问题需要解决。但毫无疑问，这将是业界关注的重点。就像云原生一样，开发者端的关注度还不够，但在企业端已经是一个流行热词。云原生在策划 12 月 6 日 ArchSummit 架构师会议的时候，也和业界技术专家沟通过，如果我们要传递未来 3 年能引领技术人关注点的未来架构技术专题的时候，应该如何设置这个专题？专家们一致认为，云原生是真正的未来架构演化方向。容器 Kubernetes 和云原生新架构慢慢成为下一代软件架构新标准，重构整个软件生命周期，对整个 IT 产业基础设施带来改变，成为释放云价值和云能力的最短路径。而 5G、边缘计算、IoT 万物互联都是具体场景，有垂直化领域内的价值和空间，可以基于云原生技术体系去构建和支撑。毫不夸张地讲，云原生会是一个改变软件应用开发模式的技术，一是节省了基础设施的部署，二是节省了开发人员的时间和精力，更专注于解决业务层面的问题，云原生开发也被视为技术人的福音。以往的单体系统可以在云端不断扩展规模，但当某一个功能成为瓶颈时，只能不断复制整个单体系统从而达到对单一功能扩展的效果，这就浪费了大量的计算资源。从云单体系统向云原生架构改造需要采用微服务、Serverless 计算等多种云原生技术。记得 Mobvista Tech VP 蔡超分享过，在构建云原生架构的时候，引入了面向容错、面向故障恢复的架构和混沌工程，从而构建一个高可用的微服务架构。这些使得系统架构更加具有弹性，从而可以更好利用云端的高弹性资源，而高弹性计算资源往往具有更好的价格优势。反应式架构

国内最早探索这一架构模式的是淘宝网，因为他们遇到了“同步等待造成资源浪费、无法实现纯业务依赖并发、响应时间累积导致连锁反应”等问题。经过调研，淘宝架构团队认为使用反应式架构是当前可行的一个方案。原因包括，Java 8 已经逐渐普及，且包含对 Lambda 的支持；同时 Reactive 相关的业务框架在业界已有成熟的实现，RxJava 已经广泛在大小公司中应用；最后，包括 Java 9（引入 Reactive Sreams 规范 API）、Spring 5（引入 Reactor/WebFlux）、Spring Boot 2 都开始拥抱 Reactive，说明反应式编程的确是趋势。

整个方案对业务架构的升级主要包括编程框架、中间件，以及业务方的升级。中间件的升级，包括服务框架（RPC）、网关、缓存、消息（MQ）、DB（JDBC）、限流组件、分布式跟踪系统、移动端 Rx 框架。改造后的架构如图：

落地反应式架构，需要做哪些准备呢？之前工程师主要使用同步式的思维写程序，突然要换成以流的方式编写，所以说，实施反应式架构的难点主要在于工程师的思维转换。另外，要做到全面异步化，组织必须从上到下全力支持。同时，要让业务方有动力去做异步化的改造，需要让他们认识到这么做的好处。

前端

2019 年，发展比较成熟的前端领域技术包括小程序、Serverless、Native、RN、前端中台、容器化等。移动开发方面，各大厂商不断追求通过各种方式改进研发效率。一方面，使用跨平台、动态化的技术，可以有效的减少研发成本，快速在线试错；另一方面，通过工程化的手段，通过优化架构，实现业务隔离，减少团队间的影响。

由于跨平台、动态化的开发技术带来价值越来越突出，已经占据了常规开发的大部分空间。对于更加细分的场景（高性能、强体验），以及新交互（AR、VR、移动 AI）的落地应用，Native 开发仍然扮演着统治者的角色。

今年另一个技术趋势是将”小程序”技术引入自家 App，可以实现业务的跨 App 复用，从而实现 1 次开发，2（iOS + Android) * N (N 个 App ) + 1（微信）次复用的效果。7 月在深圳 ArchSummit 会议上，阿里专家彭伟春分享了如何跨越生态实现监控小程序，去哪儿网的技术专家司徒正美分享了跨端小程序开发内容。

工程化的发展，一方面依赖于对前端架构的系统性规划和建设，另一方也有新技术来推进发展。比如 Serverless 新技术同样也能带来工程效率的大幅提升，它可以有效降低发布和运维的复杂度，通过自动化的管理方式平衡资源与成本。

AI、模式识别等技术为提升研发、运维效率带来了新的思路，类似 UI to code 的产品现阶段已经取得了不错的进展，未来某一天，一些基本的开发工作可能会被越来越智能化的工具所取代。

在未来 3 年，前端领域交互方式上可能会出现革命性的进化：新型硬件设备、更智能的如语音交互方式、全新的操作界面（脑机接口等）；其次是跨平台技术广泛应用：伴随新系统的发展（例，Fuchsia、鸿蒙），跨平台技术（语言、开发框架、开发工具）大幅降低多平台开发的成本。

而那对于中小型互联网企业，在前端技术选型上要优先考虑动态化、跨平台技术：可以有效降低研发成本，缩短研发周期，使业务诉求能够得到快速验证。