20年前，超越時(shí)代的應(yīng)用架構(gòu)設(shè)計(jì)之美

 記得自己在2003年參與的項(xiàng)目，使用了JSP、Servlet、JavaBeans和JDBC所組合的最原始的Web應(yīng)用框架。

對(duì)于一位牛逼的資深級(jí)程序員來(lái)講，這種原始的應(yīng)用框架能寫出最整齊、簡(jiǎn)潔與極致高性能的代碼。

但是軟件工程需要更多人參與進(jìn)來(lái)，原始的框架容易變得混亂，原因就在于太多純粹性的技術(shù)問(wèn)題束縛了開(kāi)發(fā)團(tuán)隊(duì)，那么參與者越多，代碼堆積的熵增就越顯著，項(xiàng)目也逐漸陷入泥潭。

因此，各種Web架構(gòu)總是被頂尖的工程師們不斷更新迭代、推陳出新，引導(dǎo)工程師們?nèi)リP(guān)注業(yè)務(wù)本身，而非瑣碎的技術(shù)問(wèn)題。

從這我們就能一窺應(yīng)用架構(gòu)設(shè)計(jì)不斷演進(jìn)的本質(zhì)——要讓開(kāi)發(fā)者掙脫技術(shù)復(fù)雜性所帶來(lái)的枷鎖，尋求更為靈活的規(guī)則與約定的設(shè)計(jì)，實(shí)現(xiàn)有序與自由的最大兼顧。

開(kāi)發(fā)者能靈活地應(yīng)對(duì)需求，專注于業(yè)務(wù)的構(gòu)建，擺脫復(fù)雜與混亂，這也是我們尋求自由之美的意義。

在那個(gè)年代，工程師們對(duì)科技生產(chǎn)力提升的嘗試遠(yuǎn)遠(yuǎn)超出了我們的想象，比較典型的例子就是EJB(Enterprise Java Beans)技術(shù)。

什么是EJB呢？封裝業(yè)務(wù)邏輯的組件，解放了開(kāi)發(fā)者的生產(chǎn)力，使開(kāi)發(fā)人員無(wú)須再操心數(shù)據(jù)庫(kù)訪問(wèn)、分布式事務(wù)處理、安全性、多線程并發(fā)問(wèn)題等瑣碎任務(wù)的編程技術(shù)。

這是在1998年提出了的架構(gòu)設(shè)計(jì)，這種技術(shù)目標(biāo)就算放到現(xiàn)在也一點(diǎn)都不過(guò)時(shí)。

EJB作為超越時(shí)代的分布式應(yīng)用架構(gòu)設(shè)計(jì)，在20年前就被廣泛應(yīng)用與嘗試，盡管它的嘗試最終失敗了，也催生出了更多偉大且流行的開(kāi)源技術(shù)框架，例如：Spring框架生態(tài)。

但是我們重新翻看那一段歷史，只是為了去欣賞EJB的分布式架構(gòu)所帶來(lái)的自由之美，欽佩天才般的科學(xué)家和IT工程師們的創(chuàng)造力以及對(duì)于未知領(lǐng)域的勇敢嘗試。

如下圖1 - 1 EJB 3.x應(yīng)用架構(gòu)示例所示：

 圖1 - 1 EJB 3.x應(yīng)用架構(gòu)示例

 

來(lái)自于我在2010年參與的一個(gè)電商項(xiàng)目，使用了分布式應(yīng)用架構(gòu)的部分應(yīng)用案例。

主要應(yīng)用EJB 3.0架構(gòu)，部署在云端跨區(qū)域的兩臺(tái)Amazon EC2虛擬節(jié)點(diǎn)，分別管理著各自的Amazon RDS MySQL數(shù)據(jù)庫(kù)。

這種分布式架構(gòu)中，每個(gè)EJB業(yè)務(wù)組件都是獨(dú)立部署在一個(gè)上下文容器中運(yùn)行，通過(guò)網(wǎng)絡(luò)互相通訊與協(xié)作，組件可在本地與遠(yuǎn)程復(fù)用，甚至實(shí)現(xiàn)了分布式事務(wù)。

對(duì)比原始框架，業(yè)務(wù)模塊被分布式組件化后，就遏制了工程無(wú)節(jié)制的代碼堆積，開(kāi)發(fā)者不用去操心復(fù)雜的事務(wù)問(wèn)題、實(shí)例管理問(wèn)題和并發(fā)安全問(wèn)題，就能極大提升團(tuán)隊(duì)協(xié)作分工的組織效率。

這就是EJB利用分布式的組件化技術(shù)，在尋求自由靈活的開(kāi)發(fā)方式上，為開(kāi)發(fā)者帶來(lái)了開(kāi)山祖師般的全新體驗(yàn)。

上圖中的EJB應(yīng)用架構(gòu)示例難道不夠優(yōu)雅嗎？

為什么最終還是無(wú)法成為行業(yè)主流而逐漸沒(méi)落呢？這其實(shí)是我們思考的關(guān)鍵。

EJB自身在部署方面的臃腫，分布式架構(gòu)的復(fù)雜性在當(dāng)時(shí)是非常重要的原因，但我認(rèn)為更關(guān)鍵的原因在于使用中間件服務(wù)造成的依賴性遠(yuǎn)大于后來(lái)居上的Spring框架生態(tài)。

開(kāi)發(fā)者對(duì)這些中間件服務(wù)的依賴嚴(yán)重，實(shí)際上就加重了對(duì)自身的限制。

對(duì)于開(kāi)發(fā)者來(lái)講，希望整個(gè)開(kāi)發(fā)過(guò)程更為靈活與自由，這是一種近乎本能性的向往；同時(shí)希望團(tuán)隊(duì)協(xié)作過(guò)程有序且清晰，這是社會(huì)分工的內(nèi)驅(qū)力。

自由與限制需要一種權(quán)衡，優(yōu)秀的平臺(tái)框架能通過(guò)精妙絕倫的技術(shù)設(shè)計(jì)，在兼顧兩者的情況下，側(cè)重開(kāi)發(fā)自由，降低平臺(tái)限制，實(shí)現(xiàn)具有美感的開(kāi)發(fā)方式，這對(duì)于我們都是至關(guān)重要的事情。

從這里我們就能看到一種流行的趨勢(shì)：Serverless（無(wú)服務(wù)器技術(shù)），本質(zhì)上就是在不斷解放開(kāi)發(fā)者的生產(chǎn)力。

例如：亞馬遜云科技于2014年率先推出的事件驅(qū)動(dòng)無(wú)服務(wù)器(event-driven serverless)計(jì)算服務(wù) Amazon Lambda.

開(kāi)發(fā)者不必再操心服務(wù)器與后端基礎(chǔ)架構(gòu)的瑣碎技術(shù)，而是借助觸發(fā)器、不同編程語(yǔ)言的功能函數(shù)，專注于業(yè)務(wù)代碼的構(gòu)建。

在文件處理、實(shí)時(shí)流、Web應(yīng)用程序、物聯(lián)網(wǎng)IoT、移動(dòng)應(yīng)用等各個(gè)關(guān)鍵領(lǐng)域，結(jié)合Amazon Lambda，可以構(gòu)建出伸縮性很強(qiáng)的基于Serverless的分布式應(yīng)用系統(tǒng)。

當(dāng)今微服務(wù)、分布式和容器技術(shù)的演進(jìn)融合之美
以Amazon為首，云計(jì)算平臺(tái)在IT基礎(chǔ)架構(gòu)中扮演著越來(lái)越重要的角色，工程師們主要談?wù)摰腤eb應(yīng)用架構(gòu)也逐步提升為云服務(wù)架構(gòu)，這時(shí)候我們已經(jīng)進(jìn)入到了云時(shí)代。

傳統(tǒng)部署架構(gòu)逐漸被云平臺(tái)所替代，在云平臺(tái)之上則是更為輕量化的微服務(wù)架構(gòu)與容器化技術(shù)，承載了主流的云應(yīng)用項(xiàng)目。

然而隨著互聯(lián)網(wǎng)用戶規(guī)模化，高并發(fā)、大規(guī)模數(shù)據(jù)所引發(fā)的問(wèn)題往往會(huì)更致命，高可用、并行提升性能的需求愈發(fā)強(qiáng)烈。

另外，項(xiàng)目中軟件系統(tǒng)的開(kāi)發(fā)規(guī)模也在不斷膨脹，單體架構(gòu)的工程化組織管理必然會(huì)隨著長(zhǎng)期維護(hù)而走向臃腫與混亂。

面對(duì)這些難題，微服務(wù)架構(gòu)為開(kāi)發(fā)者打開(kāi)了一個(gè)更為適度、自由、靈活的新局面，并且在微服務(wù)項(xiàng)目具體實(shí)施的過(guò)程中，又與分布式架構(gòu)緊密結(jié)合在了一起。

 

微服務(wù)架構(gòu)的自由之美

前幾年，我曾負(fù)責(zé)互聯(lián)網(wǎng)醫(yī)療微服務(wù)平臺(tái)的架構(gòu)設(shè)計(jì)。

這個(gè)項(xiàng)目的特點(diǎn)在于將醫(yī)療信息化的肌體裝進(jìn)互聯(lián)網(wǎng)的外殼中，因此，醫(yī)療業(yè)務(wù)的復(fù)雜性與互聯(lián)網(wǎng)的技術(shù)平臺(tái)性需要同時(shí)兼容。

如下圖1 - 2 互聯(lián)網(wǎng)醫(yī)療微服務(wù)與分布式架構(gòu)示例所示：

 圖1 - 2 互聯(lián)網(wǎng)醫(yī)療微服務(wù)與分布式架構(gòu)示例

 

網(wǎng)關(guān)與微服務(wù)之間、微服務(wù)與微服務(wù)之間、微服務(wù)與各個(gè)Amazon RDS數(shù)據(jù)分庫(kù)之間就形成了一種分布式的拓?fù)浣Y(jié)構(gòu)，另外承載高并發(fā)的關(guān)鍵微服務(wù)也可以由多實(shí)例副本形成均衡負(fù)載。

微服務(wù)模型單元要比過(guò)去EJB模型單元更粗粒度，是以服務(wù)為基準(zhǔn)而非組件，這樣就給予了架構(gòu)師更為靈活的自由度。

按需劃分適合大小的服務(wù)粒度并進(jìn)行適當(dāng)?shù)姆植迹簿筒粫?huì)對(duì)開(kāi)發(fā)者硬性規(guī)定底層需要依賴什么樣的服務(wù)，這就保證了輸出的軟件具有平臺(tái)無(wú)關(guān)性。

微服務(wù)架構(gòu)之所以能形成如此強(qiáng)大的一股潮流，其原因就在于面對(duì)互聯(lián)網(wǎng)規(guī)模化的時(shí)代，可以讓應(yīng)用架構(gòu)呈現(xiàn)出自由、靈活與開(kāi)放的一面，同時(shí)又能對(duì)軟件易于混亂的特征分而治之。

這與我們前面所說(shuō)的兼顧有序與自由的應(yīng)用架構(gòu)設(shè)計(jì)的本質(zhì)形成了很好的印證，它為開(kāi)發(fā)者應(yīng)對(duì)客戶需求的軟件應(yīng)用設(shè)計(jì)，提供了一種自由的張力，這也是工程師們不斷追求自由之美的關(guān)鍵價(jià)值。

 

容器技術(shù)的靈活之美

軟件應(yīng)用架構(gòu)發(fā)展到了微服務(wù)這個(gè)階段看起來(lái)應(yīng)該很不錯(cuò)，可是現(xiàn)在又面臨一個(gè)問(wèn)題，微服務(wù)架構(gòu)必然需要用掉更多的計(jì)算資源，而且更適合于分布式架構(gòu)環(huán)境，在采用更多機(jī)器組成的分布式網(wǎng)絡(luò)節(jié)點(diǎn)的情況下，如何才能優(yōu)化計(jì)算資源的使用？

這時(shí)候容器化技術(shù)的價(jià)值與作用就體現(xiàn)出來(lái)了,例如：Docker引擎管理的容器作為操作系統(tǒng)上的一個(gè)進(jìn)程，保證了容器之間互不影響，并且可以針對(duì)容器的CPU、內(nèi)存等計(jì)算資源進(jìn)行預(yù)先分配，容器鏡像對(duì)程序的封裝讓發(fā)布過(guò)程簡(jiǎn)單到一條命令就能正常運(yùn)行。

這樣就極大簡(jiǎn)化了服務(wù)在云服務(wù)器上的部署難度，提升了更高的效率，甚至我們可以同時(shí)部署多個(gè)版本的服務(wù)，形成生產(chǎn)與測(cè)試環(huán)境的并存。

當(dāng)我們感受到容器技術(shù)帶來(lái)的自由與靈活，可是如何讓開(kāi)發(fā)者忘卻容器管理引擎、分布式架構(gòu)部署的復(fù)雜性問(wèn)題呢？

其實(shí)在上面的微服務(wù)案例中已經(jīng)給出了答案，整個(gè)微服務(wù)實(shí)例全部由早期Amazon EC2 + Docker容器引擎的部署模式，遷移到了Amazon ECS平臺(tái)之上。

通過(guò)Amazon Fargate實(shí)現(xiàn)了Serverless部署，不用考慮容器的分布式部署問(wèn)題；在項(xiàng)目前期完全不需要考量計(jì)算資源的規(guī)劃問(wèn)題，因?yàn)樵跇I(yè)務(wù)不斷增長(zhǎng)的情況下，Amazon ECS可以實(shí)現(xiàn)計(jì)算資源的動(dòng)態(tài)伸縮，實(shí)在是太靈活了。

接下來(lái)我們就展開(kāi)聊聊在云服務(wù)架構(gòu)環(huán)境下，Amazon ECS與Serverless技術(shù)為開(kāi)發(fā)者擺脫底層環(huán)境束縛，到底帶來(lái)了哪些服務(wù)支撐。

 

Amazon云容器與Serverless技術(shù)的支撐之美

Amazon云容器的整體之美

 

當(dāng)我們擁有了微服務(wù)、分布式架構(gòu)與容器技術(shù)，那么云廠商又為此提供了怎樣的支撐呢？

我還是比較看好Amazon領(lǐng)導(dǎo)的這種云服務(wù)理念，因?yàn)锳mazon云技術(shù)正在朝著Serverless的方向進(jìn)行發(fā)展，尤其是充分利用了容器技術(shù)的出現(xiàn)，加快了這一步伐。

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

Amazon ECS希望用戶直接面對(duì)容器，而不是面對(duì)操作系統(tǒng)，也就是說(shuō)Amazon云平臺(tái)提供給用戶購(gòu)買的計(jì)算單元粒度更細(xì)致了。

那么這又帶來(lái)了什么好處呢？

其實(shí)是兩方面：

優(yōu)勢(shì)一：我們沒(méi)必要就為了部署一個(gè)服務(wù)，就得先占用一臺(tái)虛擬機(jī)OS，現(xiàn)在Amazon ECS給了一個(gè)新方案，部署維護(hù)一個(gè)Docker容器就夠了，它會(huì)自己維護(hù)計(jì)算資源的基礎(chǔ)設(shè)施。

由于資源占用少了，自然我們充值就少了；

優(yōu)勢(shì)二：現(xiàn)在的云服務(wù)大趨勢(shì)是分布式，這樣我們的應(yīng)用可以形成集群，以便增強(qiáng)系統(tǒng)高可靠性以及對(duì)服務(wù)性能的彈性伸縮管理。

Amazon ECS默認(rèn)提供的Serverless模式就讓開(kāi)發(fā)者不再顧慮運(yùn)行服務(wù)的集群分布問(wèn)題。我們只考慮要上多少Docker容器，至于放置在什么地方，哪個(gè)機(jī)房，哪臺(tái)服務(wù)器，那都是Amazon ECS的Serverless技術(shù)考慮的事情。

那么我們就用一個(gè)整體上較低的綜合成本，實(shí)現(xiàn)了一個(gè)真正強(qiáng)大的面向服務(wù)的集群環(huán)境。

而Amazon的ECS、EFS 、EC2、ECR是什么關(guān)系呢？

如下圖1 - 3 Amazon ECS、EC2架構(gòu)體系示意圖所示：

圖1 - 3 Amazon ECS、EC2架構(gòu)體系示意圖

Amazon EC2是Amazon提供的虛擬機(jī)，它與Amazon ECS共享基礎(chǔ)設(shè)施，形成相互協(xié)作。

通過(guò)Amazon EFS就可以將Amazon ECS任務(wù)的容器目錄掛載到EFS上，那么Amazon EC2實(shí)例就可以通過(guò)網(wǎng)絡(luò)文件系統(tǒng)(NFS)掛載到本地目錄的方式，去訪問(wèn)EFS中ECS容器的內(nèi)部文件。

Amazon ECR是Amazon提供的Registry倉(cāng)庫(kù)，為Amazon ECS提供容器鏡像服務(wù)，不僅使用方便，私密性也很好，而且比建立私有Registry倉(cāng)庫(kù)的維護(hù)成本要低得多。

從上述架構(gòu)介紹中，我們就可以看到Amazon云平臺(tái)是系統(tǒng)化地提供了整套云容器化解決方案。

 

Amazon ECS的Serverless架構(gòu)之美

對(duì)于Amazon ECS的管理核心就是Amazon Fargate（Amazon的Serverless技術(shù)），它可以將Amazon ECS任務(wù)（本質(zhì)上就是容器實(shí)例）放置在集群的不同位置，形成高可靠的分布式系統(tǒng)，至于服務(wù)到底放置在分布式網(wǎng)絡(luò)中的哪個(gè)計(jì)算節(jié)點(diǎn)之上，是不需要開(kāi)發(fā)者操心的。

如下圖1 - 4 Amazon ECS和Fargate技術(shù)結(jié)構(gòu)體系示意圖所示：

 圖1 - 4 Amazon ECS和Fargate技術(shù)結(jié)構(gòu)體系示意圖

 

我們只需要詳細(xì)地對(duì)容器任務(wù)和服務(wù)進(jìn)行配置描述，然后將配置提交給Amazon ECS。

Amazon Fargate會(huì)創(chuàng)建任務(wù)實(shí)例，每個(gè)任務(wù)都是獨(dú)立運(yùn)行的一個(gè)服務(wù)，每個(gè)服務(wù)并不獨(dú)占一臺(tái)計(jì)算節(jié)點(diǎn)資源，但又能通過(guò)資源配額的自動(dòng)擴(kuò)展來(lái)應(yīng)對(duì)更大的外部請(qǐng)求吞吐量。

另外針對(duì)Amazon ECS的應(yīng)用服務(wù)是基于界面配置，并不利于自動(dòng)化發(fā)布運(yùn)維服務(wù)，Amazon又進(jìn)一步提供了命令模式的Amazon Copilot，進(jìn)一步實(shí)現(xiàn)完全自動(dòng)化的CI/CD管道。

如下圖1 - 5 Copilot顯示服務(wù)狀態(tài)示例所示：

 圖1 - 5 Copilot顯示服務(wù)狀態(tài)示例

 

我們可以通過(guò)終端命令："copilot svc status"，就能拿到"ecsdemo-frontend"這個(gè)容器服務(wù)的狀態(tài)信息，通過(guò)捕獲的狀態(tài)信息。

我們可以進(jìn)行程序級(jí)的二次分析，應(yīng)用在我們的日志、運(yùn)維監(jiān)控等功能當(dāng)中。

因此Amazon ECS最大的優(yōu)勢(shì)還是在于提供了特別強(qiáng)大的圖形界面配置功能和命令運(yùn)維的工具集合功能，不僅包括了Amazon Copilot，還有Amazon ECS CLI、Amazon CDK等。

這些功能可以通過(guò)非圖形界面的終端命令方式、編程的方式(TypeScrpit、JavaScrpit、Python、Java、C#) 更全面且細(xì)粒度的創(chuàng)建與維護(hù)Amazon ECS基礎(chǔ)設(shè)施，控制和優(yōu)化Amazon ECS集群與任務(wù)。

 

展望云服務(wù)架構(gòu)的未來(lái)

通過(guò)上述各章節(jié)的描述，我們可以看到應(yīng)用服務(wù)架構(gòu)的進(jìn)步，二十年前還需要重度依賴中間件及底層服務(wù)，如今逐漸演進(jìn)到了Serverless的時(shí)代，這是無(wú)數(shù)工程師、開(kāi)源社區(qū)以及像亞馬遜云科技（Amazon Web Services）這樣的商業(yè)公司所共同努力的成果。

那么我們暢想一下云服務(wù)架構(gòu)的未來(lái)，我認(rèn)為基于云平臺(tái)的Serverless架構(gòu)應(yīng)該會(huì)成為主流模式，Serverless會(huì)讓開(kāi)發(fā)者更加關(guān)注業(yè)務(wù)本身，而非基礎(chǔ)設(shè)施與瑣碎的基礎(chǔ)技術(shù)。

但是對(duì)于開(kāi)發(fā)者來(lái)講，Serverless的優(yōu)勢(shì)在于分布式計(jì)算資源的自動(dòng)調(diào)度，但是分布式架構(gòu)的復(fù)雜特性又會(huì)讓很多開(kāi)發(fā)者難以理解。

因此，云服務(wù)廠商必然會(huì)在這個(gè)方面的基礎(chǔ)設(shè)施層進(jìn)行發(fā)力，例如Amazon EKS就是在云環(huán)境下創(chuàng)建和運(yùn)行K8s集群提供了整套解決方案，目標(biāo)就是讓開(kāi)發(fā)者不用關(guān)注復(fù)雜的分布式問(wèn)題。

我相信這種去分布式復(fù)雜化的基礎(chǔ)設(shè)施必將對(duì)應(yīng)用軟件架構(gòu)起到越來(lái)越重要的作用，也會(huì)變得越來(lái)越流行。

開(kāi)發(fā)者可以在這樣的平臺(tái)之上，既能獲得更大的自由與靈活度，專注于自己的業(yè)務(wù)功能改善，又能充分利用分布式技術(shù)優(yōu)勢(shì)，讓更多的開(kāi)發(fā)者在Serverless時(shí)代充分感受到自由之美。

報(bào)名開(kāi)啟 | 自由構(gòu)建 探索無(wú)限

亞馬遜云科技2022 Dev Day 重磅來(lái)襲，不容錯(cuò)過(guò)！

多位大咖現(xiàn)身說(shuō)法

如何用充滿“技術(shù)美感”的方式

幫助開(kāi)發(fā)者

實(shí)現(xiàn)更簡(jiǎn)單、自由、高效的開(kāi)發(fā)

此外，還有大量專家觀點(diǎn)碰撞

技術(shù)展、創(chuàng)新賽、動(dòng)手實(shí)操等環(huán)節(jié)

精彩不斷，干貨滿滿

攜手大家一起“自由構(gòu)建，探索無(wú)限”

點(diǎn)擊 https://marketing.csdn.net/p/0556be2dd6345bd277eb660eed38f11c，發(fā)現(xiàn)更多美~