容器、微服務和互聯網架構淺談

隨着雲服務的興起，企業應用正在從分層式架構逐步遷移到互聯網架構。傳統的企業應用架構通常是單一架構（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投資和收益的最優化。