利用微服務建構現代應用（一）

本文講的是<b>利用微服務建構現代應用（一）</b>，【編者的話】本文介紹了微服務如何消除傳統的整體化軟體架構存在的問題，微服務跟SOA的關系，微服務所利用的新技術如容器、編排架構等，以及使用微服務帶來的好處。

本文是關于微服務的兩篇博文中的第一篇。這篇博文介紹了微服務的背景知識，微服務所使用的新技術以及使用微服務帶來的好處。

随着網際網路公司在高度競争性的市場中需要快速靈活的複制其開發環境，應用程式的開發正變得越來越複雜。龐大并且整體的應用程式在過去是企業的競争力，但是在新的情境中卻使得快速部署新的服務成為了問題。而分散的和分布式開發會帶來組織架構上的問題。基于此，使用者的要求比過去任何時候更高 – 企業需要有效的擴充并且監控已部署的系統以確定高性能和一緻的使用者體驗。當然，這一切都需要在服務不中斷的情況下完成。

上述的這些趨勢對軟體架構模式提出了新的要求以使其能處理在目前時代下的需求。整體化的架構是一種傳統的方式，但是存在諸多問題：不易于擴充，大的代碼庫難于維護，更新過程有很大的風險，前置的準備成本等，所有這些迫使企業尋求新的方法。

在過去幾年，微服務的概念進入了人們的視野。由于其在提供子產品化、可擴充、高可用的應用方面的能力以及促進組織架構融合方面的優勢使得它迅速的被業界所接受。

在微服務之前，一個通用的軟體設計模式是使用整體化架構。在這種模式下，應用程式在開發、測試、打包和部署階段都是作為一個整體存在。代碼庫被整體編譯，應用程式被作為一個實體部署。擴充需要将應用程式的二進制檔案和依賴的庫檔案拷貝到不同的伺服器上，這些應用程式一般都是單程序運作。這種整體化架構使得持續傳遞（一種包含了快速、疊代、更新安全的軟體開發過程）變得充滿挑戰，因為哪怕是應用程式棧的最小增量版本也需要重新編譯、重新連結和測試。 

微服務是一種将應用分解成小的自治服務的軟體架構。服務通常僅關注某個特定的目标并保證服務之間的自治。每個服務被獨立的開發、測試和部署，每個服務往往使用約定的API并通過網絡進行通信，雖然在某些情況下網絡可能是本地的。

微服務從SOA發展而來，SOA在本世紀初曾獲得廣泛的認可和流行，SOA是一種反對大型的整體化架構應用的方式。SOA和微服務的主要差別有：

SOAs是有狀态的，而微服務是無狀态的

SOAs傾向于使用企業級的服務總線進行通信，而微服務則使用更簡單的通信系統

SOAs或許會有上百萬行代碼，而微服務往往僅有少于100行代碼

SOAs強調重用（例如運作時代碼、資料庫等），而微服務則關注在盡量解耦

SOAs裡的一個系統性變化需要修改軟體的整體結構，而在微服務中的一個系統性變化将産生一個新的服務

SOAs更經常使用傳統的關系型資料庫，而微服務則更傾向于現代的、非關系型資料庫。下面幾節将介紹在微服務架構中使用非關系型資料庫的好處。

許多架構師發現SOA存在通信協定的問題和缺乏有效的如何分割服務的指導，這些問題構成了微服務的基礎，使得微服務成為了實作一個真正的SOA的最佳實踐方法。

需要部署成百甚至上千的服務的缺點跟微服務帶來的好處（快速開發、可擴充）相比還是值得的。

新的技術的出現例如容器（Docker、LXC）和編排架構（Kubernetes、Mesos）消除了過去阻礙微服務架構使用的很多問題。

容器是輕量級的運作時環境，使用最少的性能和容量影響提供了隔離性和可擴充性。程式打包也被簡化成了相同的環境可以同時支援開發、支援、測試和生産環境的版本，是以使得從開發到測試到QA到生産的過程變得更容易。容器在微服務環境中可以工作的很好因為它可以将服務隔離在單個的容器中。更新一個服務變成了一個可以自動化和可控的過程，在APIs保持不變的情況下修改一個服務不會影響到其它的服務。

<a href="http://dockerone.com/uploads/article/20160511/7ef8b0bd9ba8c7d7103d3343b83cbf49.png" target="_blank"></a>

圖1：微服務中的容器

當組織開始在大規模環境中運作容器時，或許需要考慮使用編排架構來管理持續增加的複雜性。編排架構幫助部署和管理容器：部署主機、示例容器、錯誤處理、彈性伸縮。Kubernetes和Mesos是兩個常見的編排架構可以使得在微服務環境中部署大量容器變得容易。

很多組織可以通過實施微服務來滿足現代應用的需求，這些好處包括：

縮短産品上市時間：在整體化架構的應用中，任何微小的修改都需要重新部署整個應用棧，是以帶來了更高的風險和複雜度。這造成了更長的版本周期，因為修改可能會被累積，直到達到某個門檻值時才釋出新的版本。使用微服務，對于某個服務的修改可以被迅速的送出、測試和部署，因為對此服務的修改跟系統的其它部分是不相關的。 

持續內建——一種每天數次內建和測試開發人員的代碼改動的軟體開發實踐 – 因為有更少的功能需要去測試而變得更簡單和快速。結果是版本的釋出節奏更快，因為更少的代碼需要被編譯和重新測試。編排架構例如Kubernetes通過自動化上線、容器滾動更新和必要時的復原進一步加快了産品上市的節奏。

靈活性和可擴充性：整體架構的應用需要系統中的全部元件同時擴充。如果某個服務需要更高的性能，唯一的選項就是擴充系統中的所有服務而不是僅僅擴充需要擴容的單個服務。使用微服務，僅需要額外能力的單個服務需要擴容。擴容通過部署更多的容器來實作、可以實作更有效的容量計劃，更少的軟體授權和更低的總體擁有成本；因為服務和軟體可以更好的比對。

<a href="http://dockerone.com/uploads/article/20160511/1e782fcf8c0d0d693ffc75454925ee38.png" target="_blank"></a>

圖2：容器伸縮

彈性： 整體架構應用的一個主要問題是當某個服務失效時可能整個系統可能都會受到連累。在微服務中，各個服務之間的隔離性使得單個服務的失效不會擴充到系統的其它部分進而造成全局性的影響。如果使用容器，編排架構可以提供額外的彈性：當某個容器失效時，一個新的容器會被啟動，進而實作完全的備援和容量。 

組織架構比對：微服務可以更好的比對組織架構，因為團隊的規模可以根據需要完成的任務進行更好的定義。團隊可以被分成更小的小組并專注在應用的某個元件上。這對分布在不同地理位置的團隊來講是非常有用的。例如，在新加坡的團隊處理三個服務，在舊金山的團隊處理五個服務，這兩個團隊可以獨立的釋出和部署功能元件。 這可以幫助處理相同元件的不同職能的團隊（Ops、Dev、QA）打破疆界和更好的合作。這也可以保證不同團隊之間的溝通跟不同的服務之間的API相比對。本質上來講，服務之間的API定義了不同開發團隊之間應該互相提供的服務的契約。 

降低成本：通過使用容器，應用和環境（設計、測試、生産、支援）可以共享相同的基礎設施，結果是更高的硬體使用率和由于管理簡化帶來的成本降低。另外，微服務也會降低技術方面的開銷。在整體化架構的應用中，重構一個大型應用的代碼會帶來開銷（時間、資源）。通過将應用分解成可以通過API通路的微服務，代碼重構可以逐個服務進行，結果是更少的時間去維護和更新代碼。

這篇博文系列的第二部分，我們将讨論如何用MongoDB建構微服務。 

================================================================

譯者介紹

李光成，IBM中國研究院資深研究員，研究方向是雲計算基礎設施及技術。目前在做的是Docker資源隔離方面的研究項目。

原文釋出時間為：2016-05-11

本文作者：liguangcheng 

本文來自雲栖社群合作夥伴DockerOne，了解相關資訊可以關注DockerOne。

原文标題：利用微服務建構現代應用（一）