19

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

 4 years ago
source link: http://mp.weixin.qq.com/s?__biz=MzIxNzU1Nzk3OQ%3D%3D&%3Bmid=2247489509&%3Bidx=2&%3Bsn=0f95f77af2fe53f07d810a0b8061fee2
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

code小生  一个专注大前端领域的技术平台 公众号回复 Android 加入安卓技术群

全网最新 程序员编程视频教程分享

作者丨小智、薛梁

来源|infoQ

整理|君未读

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

背   景

在过去的十年时间里,软件开发的各个领域里发生了巨大的变化。云计算从虚拟机到容器再到云原生;数据库从关系型到 NoSQL 再到 NewSQL;运维从手工运维到 DevOps、AIOps……而在相对稳定的架构领域,也经历了从单体应用到 SOA 再到微服务的演化过程。

在固有印象里,软件开发领域更新换代最快的当属前端领域,“别更新了,学不动了”、“前端领域十八个月难度翻一番”,这是前端开发们的自嘲。但在过去的一年中,相对稳定的架构领域同样发生了巨大的变更,所谓中台、云原生带来的云时代架构,这些对企业技术架构带来了深切的影响。

过去几年间,上云成了互联网企业的主旋律,而到今年,该上云的互联网企业基本都已经完成了上云步骤,传统企业也在评估着单云多云混合云的部署方案。全面云计算时代已经来临,与之相匹配的云时代的架构又该是怎样的呢?本文试图梳理过去一年时间里,架构领域发生的种种变化,为读者揭示一个软件架构过去与未来的全貌。

中   台

2019 年可以称得上是中台元年,这一年如雨后春笋般涌现的中台名词不胜枚举,业务中台、数据中台、技术中台、算法中台、AI 中台等等让人目不暇接。一般而言,互联网企业的“中台”战略由阿里巴巴首先提出,但中台的思想其实在银行业、硅谷等都有落地经验。

阿里的中台是个累积的过程,从 2009 年建立共享事业部开始,几经曲折,但是一直在积累,直到 2015 年正式发展成中台战略。阿里目前的中台大约有十几个共享业务单元,包括用户中心、商品中心、交易中心等。淘宝、天猫、聚划算等 25 个大型业务应用都是由中台的共享业务单元支持的,共享业务单元则由阿里云平台支持。

fErmMrN.jpg!web

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

无独有偶,硅谷虽然没有“中台”一词,但类似的中台建设实践早已有之。此前亚马逊 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 可以视为更小的、原子化的服务,天然地契合微服务的一些理念。

YzYFJfQ.jpg!web

(许晓斌 《从微服务到 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 框架。改造后的架构如图:

ma2ABjv.jpg!web

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

前   端

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、鸿蒙),跨平台技术(语言、开发框架、开发工具)大幅降低多平台开发的成本。

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

写在最后

你知道 Android 为什么会 Crash 吗

Android实现八大行星绕太阳3D旋转效果

商品详情页RecyclerView与TabLayout的联动定位

B3Q7faa.jpg!web

如果你想要跟大家分享你的文章

欢迎投稿

:point_down: 阅读原文适合提升自己


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK