容器、微服務和網際網路架構淺談

隨著雲服務的興起，企業應用正在從分層式架構逐步遷移到網際網路架構。傳統的企業應用架構通常是單一架構（Monolithic），即典型的MVC三層架構。以一個主流的J2EE企業應用而言，其按照模型（資料層）——控制器（服務層）——檢視（訪問層）進行構建，然後打包為一個war包，部署執行於J2EE應用伺服器上，例如Tomcat、JBoss、WebLogic等。 


然而，經過多年應用，Monolithic架構也逐漸老化，越來越不適應技術的發展。首先，隨著加入的應用功能增多，產生了程式碼堆積現象，系統越來越龐大和複雜。尤其是引入敏捷開發後，產生了較多問題。例如應用持續整合方法時，自動載入、編譯、載入、測試整個應用程式碼的時間過長，不能快速形成正反饋。其次，元件與元件之間的耦合性太強，所有應用都執行在伺服器上的相同程式中。應用規模增大後，只有同時增加應用的副本，將多個副本部署到多個伺服器上，無法實現彈性伸縮。最後，開發團隊之間，工作交集複雜，協調耗散大。 
從長期實踐看，Monolithic架構天然的不具備健壯性，因為一旦某個元件出現問題，整個服務基本上就掛了。自身不具備分散式服務能力，通常需要依賴於負載均衡器、資料庫HA等來實現服務的分佈化和負載分擔。相對而言，網際網路架構優勢在於分散式、去中心化，支援彈性伸縮。其核心是輕應用、微服務。微服務架構也是從Monolithic架構演進來的。Monolithic應用中按照職責的不同，拆分解耦成一個個的單獨微服務（Micro Services），每個微服務都對應了一個獨立的業務功能，也只定義了該功必須的一些操作。從下圖可以形象的說明。 


微服務獨自或者共同部署在多臺應用伺服器上，微服務之間透過標準的Restful介面實現訪問。這樣當一個微服務出現問題時，並不會影響到其他的服務。而且，微服務可以基於資源的需求進行獨立擴充套件，可以被部署在更小的主機上。各個微服務使用的開發語言也可以不同，只要保持介面協議統一。 
隨著移動網際網路的爆發，越來越多的採用前端手機APP（Native或HTML5）+後端應用（Java、NodeJS等）的開發/部署模式，兩者之間通常採用Restful方式實現通訊，天然的實現了前臺和後臺的解耦，這也為微服務的流行提供了根本動力。
然而，不容忽視的是，微服務同樣存在一些劣勢。因為微服務通常部署在多個主機上，所以大量微服務的管理也成為一個難題。如果微服務使用不同的程式語言將開發，這就意味著每個服務的部署都需要完全不同的庫和框架，從而服務的部署會非常複雜。 
幸運的是，Linux容器技術的使用可以很大程度上緩解微服務架構所帶來的問題。Linux容器技術使用了類似cnames和namespaces這樣的核心介面，它允許不同容器共享相同的核心，同時容器之間還進行了完全的隔離。 
目前流行的Linux容器主要有Docker和Rocket。以Docker為例，Docker執行環境使用了一個被稱為libcontainer的模組，它標準化了這些介面。Docker同樣為容器映象提供了一個類GitHub的資源庫DockerHub，讓容器的共享和釋出非常簡單，也正是這種相同主機上的容器隔離簡易了不同語言開發的微服務程式碼部署。使用Docker，我們可以建立一個DockerFile來描述所有用到的語言、框架和服務間庫的依賴性。 



將微服務應用放置在容器中，帶來了快速與可移植性。從開發、測試、上線，實現了“一次編寫，到處執行”。 

總之，透過容器、微服務的有效結合應用，最終幫助企業應用演進到網際網路架構，實現IT投資和收益的最最佳化。