20年前，超越時代的應用架構設計之美

記得自己在2003年參與的專案，使用了JSP、Servlet、JavaBeans和JDBC所組合的最原始的Web應用框架。

對於一位牛逼的資深級程式設計師來講，這種原始的應用框架能寫出最整齊、簡潔與極致高效能的程式碼。

但是軟體工程需要更多人參與進來，原始的框架容易變得混亂，原因就在於太多純粹性的技術問題束縛了開發團隊，那麼參與者越多，程式碼堆積的熵增就越顯著，專案也逐漸陷入泥潭。

因此，各種Web架構總是被頂尖的工程師們不斷更新迭代、推陳出新，引導工程師們去關注業務本身，而非瑣碎的技術問題。

從這我們就能一窺應用架構設計不斷演進的本質——要讓開發者掙脫技術複雜性所帶來的枷鎖，尋求更為靈活的規則與約定的設計，實現有序與自由的最大兼顧。

開發者能靈活地應對需求，專注於業務的構建，擺脫複雜與混亂，這也是我們尋求自由之美的意義。

在那個年代，工程師們對科技生產力提升的嘗試遠遠超出了我們的想象，比較典型的例子就是EJB（Enterprise Java Beans）技術。

什麼是EJB呢？封裝業務邏輯的元件，解放了開發者的生產力，使開發人員無須再操心資料庫訪問、分散式事務處理、安全性、多執行緒併發問題等瑣碎任務的程式設計技術。

這是在1998年提出了的架構設計，這種技術目標就算放到現在也一點都不過時。

EJB作為超越時代的分散式應用架構設計，在20年前就被廣泛應用與嘗試，儘管它的嘗試最終失敗了，也催生出了更多偉大且流行的開源技術框架，例如：Spring框架生態。

但是我們重新翻看那一段歷史，只是為了去欣賞EJB的分散式架構所帶來的自由之美，欽佩天才般的科學家和IT工程師們的創造力以及對於未知領域的勇敢嘗試。

如下圖1 - 1 EJB 3。x應用架構示例所示：

圖1 - 1 EJB 3。x應用架構示例

來自於我在2010年參與的一個電商專案，使用了分散式應用架構的部分應用案例。

主要應用EJB 3。0架構，部署在雲端跨區域的兩臺Amazon EC2虛擬節點，分別管理著各自的Amazon RDS MySQL資料庫。

這種分散式架構中，每個EJB業務元件都是獨立部署在一個上下文容器中執行，透過網路互相通訊與協作，元件可在本地與遠端複用，甚至實現了分散式事務。

對比原始框架，業務模組被分散式元件化後，就遏制了工程無節制的程式碼堆積，開發者不用去操心複雜的事務問題、例項管理問題和併發安全問題，就能極大提升團隊協作分工的組織效率。

這就是EJB利用分散式的元件化技術，在尋求自由靈活的開發方式上，為開發者帶來了開山祖師般的全新體驗。

上圖中的EJB應用架構示例難道不夠優雅嗎？

為什麼最終還是無法成為行業主流而逐漸沒落呢？這其實是我們思考的關鍵。

EJB自身在部署方面的臃腫，分散式架構的複雜性在當時是非常重要的原因，但我認為更關鍵的原因在於使用中介軟體服務造成的依賴性遠大於後來居上的Spring框架生態。

開發者對這些中介軟體服務的依賴嚴重，實際上就加重了對自身的限制。

對於開發者來講，希望整個開發過程更為靈活與自由，這是一種近乎本能性的嚮往；同時希望團隊協作過程有序且清晰，這是社會分工的內驅力。

自由與限制需要一種權衡，優秀的平臺框架能透過精妙絕倫的技術設計，在兼顧兩者的情況下，側重開發自由，降低平臺限制，實現具有美感的開發方式，這對於我們都是至關重要的事情。

從這裡我們就能看到一種流行的趨勢：Serverless（無伺服器技術），本質上就是在不斷解放開發者的生產力。

例如：亞馬遜雲科技於2014年率先推出的事件驅動無伺服器（event-driven serverless）計算服務 Amazon Lambda。

開發者不必再操心伺服器與後端基礎架構的瑣碎技術，而是藉助觸發器、不同程式語言的功能函式，專注於業務程式碼的構建。

在檔案處理、實時流、Web應用程式、物聯網IoT、移動應用等各個關鍵領域，結合Amazon Lambda，可以構建出伸縮性很強的基於Serverless的分散式應用系統。

當今微服務、分散式和容器技術的演進融合之美

以Amazon為首，雲計算平臺在IT基礎架構中扮演著越來越重要的角色，工程師們主要談論的Web應用架構也逐步提升為雲服務架構，這時候我們已經進入到了雲時代。

傳統部署架構逐漸被雲平臺所替代，在雲平臺之上則是更為輕量化的微服務架構與容器化技術，承載了主流的雲應用專案。

然而隨著網際網路使用者規模化，高併發、大規模資料所引發的問題往往會更致命，高可用、並行提升效能的需求愈發強烈。

另外，專案中軟體系統的開發規模也在不斷膨脹，單體架構的工程化組織管理必然會隨著長期維護而走向臃腫與混亂。

面對這些難題，微服務架構為開發者打開了一個更為適度、自由、靈活的新局面，並且在微服務專案具體實施的過程中，又與分散式架構緊密結合在了一起。

微服務架構的自由之美

前幾年，我曾負責網際網路醫療微服務平臺的架構設計。

這個專案的特點在於將醫療資訊化的肌體裝進網際網路的外殼中，因此，醫療業務的複雜性與網際網路的技術平臺性需要同時相容。

如下圖1 - 2 網際網路醫療微服務與分散式架構示例所示：

圖1 - 2 網際網路醫療微服務與分散式架構示例

閘道器與微服務之間、微服務與微服務之間、微服務與各個Amazon RDS資料分庫之間就形成了一種分散式的拓撲結構，另外承載高併發的關鍵微服務也可以由多例項副本形成均衡負載。

微服務模型單元要比過去EJB模型單元更粗粒度，是以服務為基準而非元件，這樣就給予了架構師更為靈活的自由度。

按需劃分適合大小的服務粒度並進行適當的分佈，也就不會對開發者硬性規定底層需要依賴什麼樣的服務，這就保證了輸出的軟體具有平臺無關性。

微服務架構之所以能形成如此強大的一股潮流，其原因就在於面對網際網路規模化的時代，可以讓應用架構呈現出自由、靈活與開放的一面，同時又能對軟體易於混亂的特徵分而治之。

這與我們前面所說的兼顧有序與自由的應用架構設計的本質形成了很好的印證，它為開發者應對客戶需求的軟體應用設計，提供了一種自由的張力，這也是工程師們不斷追求自由之美的關鍵價值。

容器技術的靈活之美

軟體應用架構發展到了微服務這個階段看起來應該很不錯，可是現在又面臨一個問題，微服務架構必然需要用掉更多的計算資源，而且更適合於分散式架構環境，在採用更多機器組成的分散式網路節點的情況下，如何才能最佳化計算資源的使用？

這時候容器化技術的價值與作用就體現出來了，例如：Docker引擎管理的容器作為作業系統上的一個程序，保證了容器之間互不影響，並且可以針對容器的CPU、記憶體等計算資源進行預先分配，容器映象對程式的封裝讓釋出過程簡單到一條命令就能正常執行。

這樣就極大簡化了服務在雲伺服器上的部署難度，提升了更高的效率，甚至我們可以同時部署多個版本的服務，形成生產與測試環境的並存。

當我們感受到容器技術帶來的自由與靈活，可是如何讓開發者忘卻容器管理引擎、分散式架構部署的複雜性問題呢？

其實在上面的微服務案例中已經給出了答案，整個微服務例項全部由早期Amazon EC2 + Docker容器引擎的部署模式，遷移到了Amazon ECS平臺之上。

透過Amazon Fargate實現了Serverless部署，不用考慮容器的分散式部署問題；在專案前期完全不需要考量計算資源的規劃問題，因為在業務不斷增長的情況下，Amazon ECS可以實現計算資源的動態伸縮，實在是太靈活了。

接下來我們就展開聊聊在雲服務架構環境下，Amazon ECS與Serverless技術為開發者擺脫底層環境束縛，到底帶來了哪些服務支撐。

Amazon雲容器與Serverless技術的支撐之美

Amazon雲容器的整體之美

當我們擁有了微服務、分散式架構與容器技術，那麼雲廠商又為此提供了怎樣的支撐呢？

我還是比較看好Amazon領導的這種雲服務理念，因為Amazon雲技術正在朝著Serverless的方向進行發展，尤其是充分利用了容器技術的出現，加快了這一步伐。

前述案例中的Amazon ECS全稱是（Amazon Elastic Container Service），它是針對容器技術高度彈性的管理服務。

Amazon ECS希望使用者直接面對容器，而不是面對作業系統，也就是說Amazon雲平臺提供給使用者購買的計算單元粒度更細緻了。

那麼這又帶來了什麼好處呢？

其實是兩方面：

優勢一：我們沒必要就為了部署一個服務，就得先佔用一臺虛擬機器OS，現在Amazon ECS給了一個新方案，部署維護一個Docker容器就夠了，它會自己維護計算資源的基礎設施。

由於資源佔用少了，自然我們充值就少了；

優勢二：現在的雲服務大趨勢是分散式，這樣我們的應用可以形成叢集，以便增強系統高可靠性以及對服務效能的彈性伸縮管理。

Amazon ECS預設提供的Serverless模式就讓開發者不再顧慮執行服務的叢集分佈問題。我們只考慮要上多少Docker容器，至於放置在什麼地方，哪個機房，哪臺伺服器，那都是Amazon ECS的Serverless技術考慮的事情。

那麼我們就用一個整體上較低的綜合成本，實現了一個真正強大的面向服務的叢集環境。

而Amazon的ECS、EFS 、EC2、ECR是什麼關係呢？

如下圖1 - 3 Amazon ECS、EC2架構體系示意圖所示：

圖1 - 3 Amazon ECS、EC2架構體系示意圖

Amazon EC2是Amazon提供的虛擬機器，它與Amazon ECS共享基礎設施，形成相互協作。

透過Amazon EFS就可以將Amazon ECS任務的容器目錄掛載到EFS上，那麼Amazon EC2例項就可以透過網路檔案系統（NFS）掛載到本地目錄的方式，去訪問EFS中ECS容器的內部檔案。

Amazon ECR是Amazon提供的Registry倉庫，為Amazon ECS提供容器映象服務，不僅使用方便，私密性也很好，而且比建立私有Registry倉庫的維護成本要低得多。

從上述架構介紹中，我們就可以看到Amazon雲平臺是系統化地提供了整套雲容器化解決方案。

Amazon ECS的Serverless架構之美

對於Amazon ECS的管理核心就是Amazon Fargate（Amazon的Serverless技術），它可以將Amazon ECS任務（本質上就是容器例項）放置在叢集的不同位置，形成高可靠的分散式系統，至於服務到底放置在分散式網路中的哪個計算節點之上，是不需要開發者操心的。

如下圖1 - 4 Amazon ECS和Fargate技術結構體系示意圖所示：

圖1 - 4 Amazon ECS和Fargate技術結構體系示意圖

我們只需要詳細地對容器任務和服務進行配置描述，然後將配置提交給Amazon ECS。

Amazon Fargate會建立任務例項，每個任務都是獨立執行的一個服務，每個服務並不獨佔一臺計算節點資源，但又能透過資源配額的自動擴充套件來應對更大的外部請求吞吐量。

另外針對Amazon ECS的應用服務是基於介面配置，並不利於自動化釋出運維服務，Amazon又進一步提供了命令模式的Amazon Copilot，進一步實現完全自動化的CI/CD管道。

如下圖1 - 5 Copilot顯示服務狀態示例所示：

圖1 - 5 Copilot顯示服務狀態示例

我們可以透過終端命令：“copilot svc status”，就能拿到“ecsdemo-frontend”這個容器服務的狀態資訊，透過捕獲的狀態資訊。

我們可以進行程式級的二次分析，應用在我們的日誌、運維監控等功能當中。

因此Amazon ECS最大的優勢還是在於提供了特別強大的圖形介面配置功能和命令運維的工具集合功能，不僅包括了Amazon Copilot，還有Amazon ECS CLI、Amazon CDK等。

這些功能可以透過非圖形介面的終端命令方式、程式設計的方式（TypeScrpit、JavaScrpit、Python、Java、C#） 更全面且細粒度的建立與維護Amazon ECS基礎設施，控制和最佳化Amazon ECS叢集與任務。

展望雲服務架構的未來

透過上述各章節的描述，我們可以看到應用服務架構的進步，二十年前還需要重度依賴中介軟體及底層服務，如今逐漸演進到了Serverless的時代，這是無數工程師、開源社群以及像亞馬遜雲科技（Amazon Web Services）這樣的商業公司所共同努力的成果。

那麼我們暢想一下雲服務架構的未來，我認為基於雲平臺的Serverless架構應該會成為主流模式，Serverless會讓開發者更加關注業務本身，而非基礎設施與瑣碎的基礎技術。

但是對於開發者來講，Serverless的優勢在於分散式計算資源的自動排程，但是分散式架構的複雜特性又會讓很多開發者難以理解。

因此，雲服務廠商必然會在這個方面的基礎設施層進行發力，例如Amazon EKS就是在雲環境下建立和執行K8s叢集提供了整套解決方案，目標就是讓開發者不用關注複雜的分散式問題。

我相信這種去分散式複雜化的基礎設施必將對應用軟體架構起到越來越重要的作用，也會變得越來越流行。

開發者可以在這樣的平臺之上，既能獲得更大的自由與靈活度，專注於自己的業務功能改善，又能充分利用分散式技術優勢，讓更多的開發者在Serverless時代充分感受到自由之美。

報名開啟 | 自由構建 探索無限

亞馬遜雲科技2022 Dev Day 重磅來襲，不容錯過！

多位大咖現身說法

如何用充滿“技術美感”的方式

幫助開發者

實現更簡單、自由、高效的開發

此外，還有大量專家觀點碰撞

技術展、創新賽、動手實操等環節

精彩不斷，乾貨滿滿

攜手大家一起“自由構建，探索無限”