从微服务跨越到中台,架构领域年度盘点!
作者 | 小智、薛梁
来源丨订阅号 InfoQ2019 年,整个 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、鸿蒙),跨平台技术(语言、开发框架、开发工具)大幅降低多平台开发的成本。
而那对于中小型互联网企业,在前端技术选型上要优先考虑动态化、跨平台技术:可以有效降低研发成本,缩短研发周期,使业务诉求能够得到快速验证。
写在最后Gartner 每年都会发布一份技术炒作周期的研究报告,提出他们认为未来值得关注的技术趋势。许多人认为技术炒作周期的中文译名不太妥当,笔者却认为恰到好处。在当下的中文 IT 圈,关于中台、Service Mesh、云原生的炒作力度不可谓不大。但回顾过去二十年 Gartner 的技术炒作周期报告,你会发现:人们的预测能力非常差,预测即打脸;昙花一现的技术非常多;许多技术都死掉了……但同样的,仍旧有一些技术一直在成熟的过程中,许多成熟技术在持续取得进步,今天回看过去十年、二十年的技术发展,你才会深刻地认识到,原来技术从真正意义上地改变了世界。而对于技术而言,IT 架构是支撑其高速发展的根本,单个技术的力量是有限的,只有组合在一起,才能产生沛然莫之能御的力量。软件的颠覆式创新,一定是在硬件支持的基础上,随着现有的软件架构对现有硬件能力的挖掘,再发生颠覆的可能性已经较小了。但对于身处技术变革洪流中的开发者本身而言,仍旧不可轻视,了解架构发展的现在与未来,才能更好地在诸般变化中找到本源,处变不惊。1.不认命,从10年流水线工人,到谷歌上班的程序媛,一位湖南妹子的励志故事
4.“37岁,985毕业,年薪50万,被裁掉只用了10分钟”
5.37岁程序员被裁,120天没找到工作,无奈去小公司,结果懵了...
一个人学习、工作很迷茫?
点击「阅读原文」加入我们的小圈子!