架構的演進，阿里資深Java工程師表述架構的腐化之謎

時間 2019-12-05

原文原文鏈接

前言nginx

新技術層出不窮。過去十年時間裏，咱們經歷了許多激動人心的新技術，包括那些新的框架、語言、平臺、編程模型等等。這些新技術極大地改善了開發人員的工做環境，縮短了產品和項目的面世時間。然而做爲在軟件行業第一線工做多年的從業者，咱們卻不得不面對一個現實，那就是當初採用新技術的樂趣隨着項目週期的增加而迅速減小。不管當初的選擇多麼光鮮，半年、一年以後，只要這個項目依然活躍，業務在擴張——愈來愈多的功能須要加入，一些公共的問題就會逐漸顯露出來。構建過慢，完成新功能讓你痛不欲生，團隊成員沒法很快融入，文檔沒法及時更新等等。git

在長期運轉的項目中，架構的腐化是怎麼產生的？爲何常見的面向對象技術沒法解決這類問題？如何延緩架構的腐化？程序員

本文將嘗試解釋這一切，並提出相應的解決方案。讀者須要具有至關的開發經驗——至少在同一個項目的開發上一年以上；公司負責架構演進、產品演進的角色會從本文找到靈感。數據庫

架構編程

架構這個詞在各類場合不斷地以各類面目表現出來。從維基百科的詞條看來，咱們常常聽到的有插件架構（Plugin），以數據庫爲中心的架構（Database Centric），模型-視圖-控制器架構（MVC），面向服務的架構（SOA），三層模型(Three-Tier model)，模型驅動架構（MDA）等等等等。奇妙的是，這些詞越大，實際的開發者就越痛苦。SOA很好——但在它提出的那個年代，帶給開發者的只是面向廠商虛無縹緲的「公共數據類型」；MDA甚至都沒有機會淪爲新一輪使人笑話的CASE工具。瀏覽器

在繼續閱讀以前，讀者不妨問本身一個問題：在長期的項目中，這些大詞是否真的切實給你帶來過好處？更爲功利的問題是：你，做爲戰鬥在一線的開發者，在長期項目中可曾有過美好的體驗？緩存

技術的演變與揮之不去的痛服務器

企業應用的發展彷佛從十年前開始騰飛。從Microsoft ASP/LAMP(Linux、Apache、MySQL、PHP)年代開始，各類企業應用紛紛向瀏覽器遷移。通過十年的發展，目前陣營已經百花齊放。與過去不一樣，如今的技術不只僅在編程語言方面，常見的編程套路、最佳實踐、方法學、社區，都是各類技術獨特擁有的。目前佔據主流的陣營有：架構

Rails框架

Java EE平臺。值得一提的是Java VM已經成爲一種新的宿主平臺，Scala、JRuby更爲活躍並引人矚目

LAMP平臺。Linux/MySQL/Apache並無多少變化，PHP社區從Rails社區得到了很多營養，出現了許多更加優秀的開發框架

Microsoft .NET平臺

Django

沒有理由對這些新技術不感到振奮。它們解決了許多它們出現以前的問題。在它們的網站上都宣稱各類生產效率如何之高的廣告語，相似於15分鐘建立一個博客應用；2分鐘快速教程等等。比起過去21天才能學會XXX，如今它們在上手難度上早已大幅度下降。

須要潑冷水的是，本文開篇提出的問題，在上述任何一種技術下，都如幽靈般揮之不去。採用Ruby on Rails的某高效團隊在10人團隊工做半年以後，構建時間從當初的2分鐘變成2小時；咱們以前採用Microsoft .NET 3.5 (C# 3.0)的一個項目，在產生2萬行代碼的時候，構建時間已經超過半小時；咱們的一些客戶，工做在10年的Java代碼庫上——他們不遺餘力，保持技術棧與時俱進：Spring、Hibernate、Struts等，面對的困境是他們須要同時打開72個項目才能在Eclipse中得到編譯；因爲編譯打包時間過長，他們去掉了大部分的單元測試——帶來巨大的質量風險。

若是你真的在一個長期的項目工做過，你應該清楚地瞭解到，這種痛苦，彷佛不是任何一種框架可以根本性解決的。這些新時代的框架解決了大部分顯而易見的問題，然而在一個長期項目中所面對的問題，它們無能爲力。

一步一步：架構是如何腐化的

不管架構師在任什麼時候代以何種絢麗的方式描述架構，開發中的項目不會超出下圖所示：

基本架構示意

針對架構的技術我建立一個Java架構學習羣:650385180，裏面會分享錄製微服務，分佈式，源碼分析，JVM，Java工程化這些專題的視頻，感興趣的朋友能夠加一下。

一些基本的準則：

爲了下降耦合，系統應當以恰當的方式進行分層。目前最經考驗的分層是MVC+Service。

爲了提供基礎的訪問，一些基本的、平臺級別的API應該被引入。用Spring之類的框架來作這件事情。

用AOP進行橫向切分業務層面共性的操做，例如日誌、權限等。

爲了保證項目正常構建，你還須要數據庫、持續集成服務器，以及對應的與環境無關的構建腳本和數據庫遷移腳本。

階段1

知足這個條件的架構在初期是很是使人愉悅的。上一部分咱們描述的框架都符合這種架構。這個階段開發很是快：IDE打開很快，開發功能完成很快，團隊這個時候每每規模較小，交流也沒有問題。全部人都很高興——由於用了新技術，由於這個架構是如此的簡單、清晰、有效。

階段2

好日子不算太長。

很快你的老闆（或者客戶，隨便什麼）有一攬子的想法要在這個團隊實現。工做有條不紊的展開。更多的功能加入進來，更多的團隊成員也加入了進來。新加入的功能也按照以前的架構方式開發着；新加入的團隊成員也對清晰的架構表示欣喜，也一絲不苟的遵循着。用不了多久——也許是三個月，或者更短，你會發現代碼庫變成下面的樣子：

正常開發以後

你也許很快會意識到這其中有什麼問題。但你很難意識到這到底意味着什麼。常見的動做每每圍繞着重構——將縱向相關的抽取出來，造成一個新的項目；橫向相關的抽取出來，造成一個名叫common或者base的項目。

不管你作什麼類型的重構，一些變化在悄悄產生（也許只是快慢的不一樣）。構建過程不可避免的變長。從剛開始的一兩分鐘變成好幾分鐘，到十幾分鍾。經過重構構建腳本，去掉那些不須要的部分，構建時間會降到幾分鐘，你滿意了，因而繼續。

階段3

更多的功能、更多的成員加入了。構建時間又變長了。隨着加載代碼的增多，IDE也慢了下來；交流也多了起來——不是全部人可以瞭解全部代碼了。在某些時候，一個頗有道德的程序員嘗試重構一部分重複邏輯，發現牽涉的代碼太多了，好多都是他看不懂的業務，因而他放棄了。更多的人這麼作了，代碼庫愈來愈臃腫，最終沒有一我的可以搞清楚系統具體是怎麼工做的了。

系統在混亂的狀態下繼續緩慢地混亂——這個過程遠比本文寫做的時間要長不少，之間會有反覆，但據我觀察，在不超過1年的時間內，不管採用何種技術框架，應用何種架構，這個過程彷佛是不可抗拒的宿命。

常見的解決方案

咱們並不是是坐以待斃的。身邊優秀的同事們在問題發現以前採起了各類解決方案。常見的解決方案以下：

升級工做環境

沒有什麼比一臺與時俱進的電腦更能激勵開發人員了。最多每隔三年，升級一次開發人員的電腦——升級到當時最好的配置，可以大幅度的提高生產效率，激勵開發人員。反過來，利用過期的電腦，在慢速的機器上進行開發，帶來的不只僅是客觀上開發效率的下降，更大程度上帶來的是開發人員心理上的懈怠。

升級的工做環境不只僅是電腦，還包括工做的空間。良好的，促進溝通的空間（以及工做方式）可以促進問題的發現從而減小問題的產生。隔斷不適合開發。

分階段的構建

通常而言，構建的順序是：本地構建確保全部的功能運行正常，而後提交等待持續集成工做正常。本地構建超過5分鐘的時候就變得難以忍受；大多數狀況下你但願這個反饋時間越短越好。項目的初期每每會運行全部的步驟：編譯全部代碼，運行全部測試。隨着項目週期的變長，代碼的增多，時間會愈來愈長。在嘗試若干次重構構建腳本再也沒辦法優化以後，「分階段構建」成爲絕大多數的選擇。經過合理的拆分、分層，每次運行特定的步驟，例如只運行特定的測試、只構建必要的部分；而後提交，讓持續集成服務器運行全部的步驟。這樣開發者可以繼續進行後續的工做。

分佈式構建

即使本地快了起來，採用分階段構建的團隊很快發現，CI服務器的構建時間也愈來愈讓人不滿意。每次提交半小時以後才能獲得構建結果太不可接受了。各類各樣的分佈式技術被建立出來。除了常見的CI服務器自己提供的能力，許多團隊也發明了本身的分佈式技術，他們每每可以將代碼分佈到多臺機器進行編譯和運行測試。這種解決方案可以在比較長的一段時間內生效——當構建變慢的時候，只須要調整分佈策略，讓構建過程運行在更多的集羣機器上，就能夠顯著的減小構建時間。

採用JRebel或者Spork

一些新的工具可以顯著地提速開發人員的工做。JRebel可以將須要編譯的Java語言變成修改、保存當即生效，減小了大量的修改、保存、從新編譯、部署的時間；Spork可以啓動一個Server，將RSpec測試相關的代碼緩存於其中，這樣在運行RSpec測試的時候就不用從新進行加載，極大提高了效率。

究竟是什麼問題？

上述的解決方案在特定的時間域內很好地解決了一部分問題。然而，在項目運轉一年，兩年或者更久，它們最終依然沒法避免構建時間變長、開發變慢、代碼變得混亂、架構晦澀難懂、新人難以上手等問題。到底問題的癥結是什麼？

人們喜歡簡潔。但這更多的看起來是一個謊話——沒有多少團隊可以自始至終保持簡潔。人們喜歡簡潔只是由於這個難以作到。並非說人們不肯意如此。不少人都知道軟件開發不比其餘的勞動力密集型的行業——人越多，產量越大。《人月神話》中已經提到，項目增長更多的人，在提高工做產出的同時，也產生了混亂。短時間內，這些混亂可以被團隊經過各類形式消化；但從長期看來，隨着團隊人員的變更（新人加入，老人離開），以及人正常天然的遺忘曲線，代碼庫會逐漸失控，混亂沒法被消化，而項目並不會中止，新功能不斷的加入，架構就在一每天的過程當中被腐蝕。

人的理解總有一個邊界，而需求和功能不會——今天的功能總比昨天的多；這個版本的功能總比上個版本的多。而在長時間的開發中，忘記以前的代碼是正常的；忘記某些約定也是正常的。造成某些小而不經意的錯誤是正常的，在巨大的代碼庫中，這些小錯誤被忽視也是正常的。這些不斷積攢的小小的不一致、錯誤，隨着時間的積累，最終變得難以控制。

不多有人注意到，規模的變大才是致使架構腐化的根源——因果關係在時空上的不連續，使得人們並不能從其中得到經驗，只是一再重複這個悲劇的循環。

解決方案

解決方案的終極目標是：在混亂髮生以前，在咱們的認知出現障礙以前，就將項目的規模控制在必定範圍以內。這並不容易。大多數團隊都有至關的交付壓力。大多數的業務用戶並無意識到，往一個項目/產品毫無節制地增長需求只會致使產品的崩潰。看看Lotus Notes，你就知道產品最終會多麼使人費解、難以使用。咱們這裏主要討論的是技術方案。業務上你也須要始終對需求的增加保持警戒。

採用新技術

這多是最廉價的、最容易採用的方案。新技術的產生每每爲了解決某些特定的問題，它們每每是經驗的集合。學習，理解這些新技術可以極大程度減小過去爲了完成某些技術目標而進行的必要的經驗積累過程。就像武俠小說中常常有離奇遭遇的主人公忽然得到某個世外高人多年的內力同樣，這些新技術可以迅速幫助團隊從某些特定的痛點中解脫出來。

已經有足夠多的例子來證實這一觀點。在Spring出現以前，開發者的基本上只能遵循J2EE模式文檔中的各類實踐，來構建本身的系統。有一些簡單的框架可以幫助這一過程，但整體來講，在處理今天看起來很基礎的如數據庫鏈接，異常管理，系統分層等等方面，還有不少手工的工做要作。Spring出現以後，你不須要花費不少精力，很快就能獲得一個系統分層良好、大部分設施已經準備就緒的基礎。這爲減小代碼庫容量以及解決可能出現的低級Bug提供了幫助。

Rails則是另一個極端的例子。Rails帶來的不只僅是開發的便利，還帶來了人們在Linux世界多年的部署經驗。數據庫Migration， Apache + FastCGI或者nginx+passenger，這些過去看起來複雜異常的技術在Rails中變得無足輕重——稍懂命令行的人便可進行部署。

任何一個組織都沒法所有擁有這些新技術。所以做爲軟件從業者，須要不斷地保持對技術社區的關注。閉門造車只能加速架構的腐化——特別是這些本身的發明在開源社區早已有成熟的方案的時候。在那些貌似光鮮的產品背後，實際上有着無數的失敗的案例成功的經驗在支撐。

咱們曾經有一個項目。在乎識到需求可能轉向相似於key-value的文檔數據庫以後，團隊大膽的嘗試採用SQLServer 2008的XML能力，在SQL Server內部實現了相似於No-SQL的數據庫。這是一個新的發明，創造者初期很興奮，終於有機會作不一樣的事情了。然而隨着項目的進行，愈來愈多的需求出現了：Migration的支持、監控、管理工具的支持、文檔、性能等等。隨着項目的進展，最終發現這些能力與時下流行的MongoDB是如此的類似 ——MongoDB已經解決了大多數的問題。這個時候，代碼庫已經有至關的規模了——而這部分的代碼，讓許多團隊成員費解；在一年以後，大約只有2我的可以瞭解其實現過程。若是在早期採用MongoDB，團隊本有機會摒棄大部分相關的工做。

值得一提的是，高傲的開發者每每對新技術不夠耐心；或者說對新技術的能力或侷限缺少足夠耐心去了解。每個產品都有其針對的問題域，對於問題域以外，新技術每每沒有成熟到可以應對的地步。開發者須要不斷地閱讀、思考、參與，來驗證本身的問題域是否與其匹配。淺嘗輒止不是好的態度，也阻礙了新技術在團隊內的推廣。

新技術的選型每每發生在項目/產品特定的時期，如開始階段，某個特定的痛點時期。平常階段，開發者仍然須要保持對代碼庫的關注。下一條，重構到物理隔離的組件則是對不斷增大的代碼庫另外一種解決方案。

重構到物理隔離的組件

顯而易見的趨勢是，對於同一個產品而言，需求老是不斷增多的。去年有100個功能，今年就有200個。去年有10萬行代碼，今年也許就有20萬行。去年2G 內存的機器可以正常開發，今年彷佛得加倍才行。去年有15個開發人員，今年就到30個了。去年構建一次最多15–20分鐘，今年就得1個小時了，還得整個分佈式的。

有人會注意到代碼的設計問題，孜孜不倦地進行着重構；有人會注意到構建變慢的問題，不懈地改進着構建時間。然而不多有人注意到代碼庫的變大才是問題的根源。不少常規的策略每每是針對組織的：例如將代碼庫按照功能模塊劃分（例如ABC功能之類）或者按層次劃分（例如持久層、表現層），但這些拆分以後的項目依然存在於開發人員的工做空間中。不管項目如何組織，開發者都須要打開全部的項目才能完成編譯和運行過程。我曾經見到一個團隊須要在Visual Studio中打開120個項目；我本身也經歷過須要在Eclipse中打開72個項目才能完成編譯。

解決方案是物理隔離這些組件。就像團隊在使用Spring/Hibernate/Asp.NET MVC/ActiveRecord這些庫的時候，不用將它們對應的源代碼放到工做空間進行編譯同樣，團隊也能夠將穩定工做的代碼單元整理出來造成對應的庫，標記版本而後直接引用二進制文件。

在不一樣的技術平臺上有着不一樣的方案。Java世界有歷史悠久的Maven庫，可以良好的將不一樣版本的 JAR以及他們的以來進行管理；.NET比較遺憾，這方面真正成熟的什麼也沒有——但參考Maven的實現，團隊本身造一個也不是難事（可能比較困難的是與MSBuild的集成）；Ruby/Rails世界則有著名的gem/bundler系統。將本身整理出來的比較獨立的模塊不要放到rails/lib /中，整理出來，造成一個新的gem，對其進行依賴引用（團隊內須要搭建本身的gems庫）。

同時，代碼庫也須要進行大刀闊斧的整改。以前的代碼結構可能以下，（這裏以SVN爲例，由於SVN有明確的trunk/branches/tags目錄結構。git/hg相似）

原來的庫結構

改進以後，將會以下圖所示：

改進的庫結構

每一個模塊都有屬於本身的代碼庫，擁有本身的獨立的升級和發佈週期，甚至有本身的文檔。

這一方案看起來很容易理解，但在實際操做過程當中則困難重重。團隊運轉很長一段時間以後，不多有人去關心模塊之間的依賴。一旦要拆分出來，去分析幾十上百個現存項目之間的依賴至關費勁。最簡單的處理辦法是，檢查代碼庫的提交記錄，例如最近3個月以內某個模塊就沒有人提交過，那麼這個模塊基本上就能夠拿出來造成二進制依賴了。

不少開源產品都是經過這個過程造成的，例如Spring（請參考閱讀《J2EE設計開發編程指南》，Rod Johnson基本上闡述了整個Spring的設計思路來源）。一旦團隊開始這樣去思考，每隔一段時間從新審視代碼庫，你會發現核心代碼庫不可能失控，同時也得到了一組設計良好、工做穩定的組件。

將獨立的模塊放入獨立的進程

上面的解決方案核心原則只有一條：始終將核心代碼庫控制在團隊能夠理解的範圍內。若是運轉良好，可以很大程度上解決架構由於代碼規模變大而腐化的問題。然而該解決方案只解決了在系統在靜態層面的隔離。當隔離出的模塊愈來愈多，系統也所以也須要愈來愈多的依賴來運行。這部分依賴在運行期分爲兩類：一類是相似於 Spring/Hibernate/Apache Commons之類的，系統運行的基礎，運行期這些必須存在；另一類是相對獨立的業務功能，例如緩存的讀取，電子商城的支付模塊等。

第二類依賴則能夠更進一步：將其放到獨立的進程中。如今稍具規模的系統，登陸、註銷功能已經從應用中脫離而出，要麼採用SSO的方案來進行登錄，要麼則乾脆代理給別的登錄系統。LiveJournal團隊在開發過程當中，發現緩存的讀寫實際上能夠放到獨立的進程中進行（而不是相似EhCache的方案，直接運行於所在的運行環境中），因而發明瞭如今鼎鼎有名的memcached. 咱們以前進行的一個項目中，發現支付模塊徹底可以獨立出來，因而將其進行隔離，造成了一個新的、沒有界面的、永遠在運行的系統，經過REST處理支付請求。在另一個出版項目中，咱們發現編輯編寫報告的過程實際上與報告發行過程雖然存在類級別的重用，但在業務層面是獨立的。最終咱們將報告發行過程作成了一個常駐服務，系統其餘的模塊經過MQ消息與其進行交互。

這一解決方案應該不難理解。與解決方案1不一樣的是，這一方案更多的是要對系統進行面向業務層面的思考。因爲系統將會以獨立的進程來運行這一模塊，在不一樣的進程中可能存在必定的代碼重複。例如Spring同時存在兩個不相關的項目中你們以爲沒什麼大不了的；但若是是本身的某個業務組件同時在同一個項目的兩個進程中重複，許多人就有些潔癖不可接受了。（題外話：這種潔癖在OSGi環境中也存在）這裏須要提醒的是：當處於不一樣的進程時，它們在物理上、運行時上已經完全隔離了。必須以進程的觀點去思考整個架構，而不是簡單的物理結構。

從單進程模型到多進程模型的架構思惟轉變也不太容易——須要架構師有意識的增強這方面的練習。流行的.NET和Java世界傾向於把什麼都放到一塊兒。而 Linux世界Rails/Django則能更好的平衡優秀產品之間的進程協調。例如memcached的使用。另外，如今多核環境愈來愈多，與其費盡心思在編程語言層面上不如享受多核的好處，多進程可以簡單而且顯著地利用多核能力。

造成高度鬆散耦合的平臺+應用

如今將眼光看更遠一些。想象一下咱們在作一個相似於開心網、Facebook、人人網的系統。它們的共同特色是可以接入幾乎無限的第三方應用，不管是買賣朋友這類簡單的應用，仍是絢麗無比的各類社交遊戲。神奇的是，實現這一點並不須要第三方應用的開發者採用跟它們同樣的技術平臺，也不須要服務端提供無限的運算能力——大部分的架構由開發方來控制。

在企業應用中實現這個並不難。這其中的祕訣在於：當用戶經過Facebook訪問某個第三方應用的時候，Facebook實際上經過後臺去訪問了第三方應用，將當前用戶的信息（以及好友信息）經過HTTP POST送到第三方應用指定的服務網址，而後將應用的HTML結果渲染到當前頁面中。某種意義上說，這種技術本質上是一種服務器端的mashup. （詳情參考InfoQ 文章）

Facebook App架構

這種架構的優勢在於極度的分佈式。從外觀上看起來一致的系統，實際由若干個耦合極低、技術架構徹底不一樣的小應用組成。它們不須要被部署在同一臺機器上，能夠單獨地開發、升級、優化。一個應用的癱瘓不影響整個系統的運行；每一個應用的自行升級對整個系統也徹底沒有影響。

這並不是是終極的解決方案，只在某些特定的條件下有效。當系統規模上很是龐大，例如由若干個子系統組成；界面基本一致；子系統之間關聯較少。針對這個前提，能夠考慮採用這種架構。抽象出極少的、真正有效公用的信息，在系統之間經過HTTP POST.。其餘的系統徹底能夠獨立開發、部署，甚至針對應用訪問的狀況進行特定的部署優化。若是不這麼作，動輒上百萬千萬行的代碼堆在一個系統中，隨着時間的推移，開發者逐漸對代碼失控，架構的腐化是早晚的事情。

例如，銀行的財務系統，包括了十多個個子系統，包括薪資、資產、報表等等模塊，每一部分功能都相對獨立而且複雜。整個系統若是按照這種方式拆分，就可以實現單點優化而無需從新啓動整個應用。針對每一個應用，開發者可以在更小的代碼內採用本身熟悉的技術方案，從而減小架構腐化的可能。

結語

沒有糟糕的架構，變化使之

我訪問過不少團隊。在不少項目開始的時候，他們花不少時間在選擇用何種技術體系，何種架構，乃至何種IDE。就像小孩子選擇本身鍾愛的玩具，我相信不管過程如何，團隊最終都會欣然選擇他們所選擇的，而且堅信他們的選擇沒有錯誤。事實也確實如此。在項目的開始階段很難有真正的架構挑戰。困難的地方在於，隨着時間的增加，人們會忘記；有不少的人加入，他們須要理解舊代碼的同時完成新功能；每一次代碼量的突破，都會引發架構的不適應；這些不適應包括：新功能引入變得困難，新人難以迅速上手；構建時間變長等等。這些可否引發團隊的警覺，而且採起結構性的解決方案而不是臨時性的。

關於文檔

不少人說敏捷不提倡文檔。他們說文檔很難寫。他們說開發人員寫不了文檔。因而就沒有文檔。

奇怪的是我看到的狀況卻不是這樣。程序寫得優秀的人，寫起文字來也很不錯。ThoughtBlogs上絕大多數都是程序員，不少人的文字寫得都很贊。

而項目中的文檔每每少得可憐。新人來了老是一頭霧水。使人奇怪的是，新人可以一天或者兩天以內經過閱讀RSpec或者JBehave迅速瞭解這些工具的使用，到了團隊裏面卻沒有了文檔。

拋開項目持續運轉並交付的特性不談，我認爲巨大的、不穩定的代碼庫是文檔迅速失效的根源。若是咱們可以按照上述的解決方案，將代碼庫縮小，那麼獨立出來的模塊或者應用就有機會在更小的範圍內具有更獨特的價值。想象一下如今的Rails3/Spring框架，他們每每有超過20個第三方依賴，咱們卻沒有以爲理解困難，最重要的緣由是依賴隔離以後，這些模塊有了獨立的文檔能夠學習。

企業級項目也能夠如此。

建立應用程序的生態環境，而非單一的項目

功能老是不斷的、不斷的加到同一個產品中。這絕不奇怪。然而經過咱們前面的分析，咱們應當從新思考這個常識。是建立一個日益龐大的、緩慢的、毫無生機的產品，仍是將其有機分解，成爲一個生機勃勃的具備不一樣依賴的生態系統？項目的各方人員（包括業務用戶、架構師、開發者）應當從短視的眼光中走出來，着眼於建立可持續的應用程序生態系統。