利用微服務構建現代應用 – 第一部分
【編者的話】本文介紹了微服務如何消除傳統的整體化軟件架構存在的問題，微服務跟SOA的關系，微服務所利用的新技術如容器、編排框架等，以及使用微服務帶來的好處。
原文鏈接： Building Modern Applications with Microservices: Part 1
譯者介紹
李光成，IBM中國研究院資深研究員，研究方向是云計算基礎設施及技術。目前在做的是Docker資源隔離方面的研究項目。
正文
本文是關于微服務的兩篇博文中的第一篇。這篇博文介紹了微服務的背景知識，微服務所使用的新技術以及使用微服務帶來的好處。
簡介
隨著互聯網公司在高度競爭性的市場中需要快速靈活的復制其開發環境，應用程序的開發正變得越來越復雜。龐大并且整體的應用程序在過去是企業的競爭力，但是在新的情境中卻使得快速部署新的服務成為了問題。而分散的和分布式開發會帶來組織架構上的問題。基于此，用戶的要求比過去任何時候更高 – 企業需要有效的擴展并且監控已部署的系統以確保高性能和一致的用戶體驗。當然，這一切都需要在服務不中斷的情況下完成。
上述的這些趨勢對軟件架構模式提出了新的要求以使其能處理在當前時代下的需求。整體化的架構是一種傳統的方式，但是存在諸多問題：不易于擴展，大的代碼庫難于維護，升級過程有很大的風險，前置的準備成本等，所有這些迫使企業尋求新的方法。
在過去幾年，微服務的概念進入了人們的視野。由于其在提供模塊化、可擴展、高可用的應用方面的能力以及促進組織架構融合方面的優勢使得它迅速的被業界所接受。
整體化架構
在微服務之前，一個通用的軟件設計模式是使用整體化架構。在這種模式下，應用程序在開發、測試、打包和部署階段都是作為一個整體存在。代碼庫被整體編譯，應用程序被作為一個實體部署。擴展需要將應用程序的二進制文件和依賴的庫文件拷貝到不同的服務器上，這些應用程序一般都是單進程運行。這種整體化架構使得持續交付（一種包含了快速、迭代、升級安全的軟件開發過程）變得充滿挑戰，因為哪怕是應用程序棧的最小增量版本也需要重新編譯、重新鏈接和測試。
什么是微服務?
微服務是一種將應用分解成小的自治服務的軟件架構。服務通常僅關注某個特定的目標并保證服務之間的自治。每個服務被獨立的開發、測試和部署，每個服務往往使用約定的API并通過網絡進行通信，雖然在某些情況下網絡可能是本地的。
微服務從SOA發展而來，SOA在本世紀初曾獲得廣泛的認可和流行，SOA是一種反對大型的整體化架構應用的方式。SOA和微服務的主要區別有：
? SOAs是有狀態的，而微服務是無狀態的
? SOAs傾向于使用企業級的服務總線進行通信，而微服務則使用更簡單的通信系統
? SOAs或許會有上百萬行代碼，而微服務往往僅有少于100行代碼
? SOAs強調重用（例如運行時代碼、數據庫等），而微服務則關注在盡量解耦
? SOAs里的一個系統性變化需要修改軟件的整體結構，而在微服務中的一個系統性變化將產生一個新的服務
? SOAs更經常使用傳統的關系型數據庫，而微服務則更傾向于現代的、非關系型數據庫。下面幾節將介紹在微服務架構中使用非關系型數據庫的好處。
許多架構師發現SOA存在通信協議的問題和缺乏有效的如何分割服務的指導，這些問題構成了微服務的基礎，使得微服務成為了實現一個真正的SOA的最佳實踐方法。
使微服務成為可能的新技術
需要部署成百甚至上千的服務的缺點跟微服務帶來的好處（快速開發，可擴展）相比還是值得的。
新的技術的出現例如容器（Docker，LXC）和編排框架（Kubernetes，Mesos）消除了過去阻礙微服務架構使用的很多問題。
容器是輕量級的運行時環境，使用最少的性能和容量影響提供了隔離性和可擴展性。程序打包也被簡化成了相同的環境可以同時支持開發、支持、測試和生產環境的版本，因此使得從開發到測試到QA到生產的過程變得更容易。容器在微服務環境中可以工作的很好因為它可以將服務隔離在單個的容器中。升級一個服務變成了一個可以自動化和可控的過程，在APIs保持不變的情況下修改一個服務不會影響到其它的服務。
當組織開始在大規模環境中運行容器時，或許需要考慮使用編排框架來管理持續增加的復雜性。編排框架幫助部署和管理容器：部署主機、示例容器、錯誤處理、彈性伸縮。Kubernetes和Mesos是兩個常見的編排框架可以使得在微服務環境中部署大量容器變得容易。
獲取更多關于如何利用容器和MongoDB構建微服務架構的信息，下載我們的指南：構建微服務：解析容器和編排
微服務的好處
很多組織可以通過實施微服務來滿足現代應用的需求，這些好處包括：
縮短產品上市時間: 在整體化架構的應用中，任何微小的修改都需要重新部署整個應用棧，因此帶來了更高的風險和復雜度。這造成了更長的版本周期，因為修改可能會被累積，直到達到某個閾值時才發布新的版本。使用微服務，對于某個服務的修改可以被迅速的提交、測試和部署，因為對此服務的修改跟系統的其它部分是不相關的。
持續集成 – 一種每天數次集成和測試開發人員的代碼改動的軟件開發實踐 – 因為有更少的功能需要去測試而變得更簡單和快速。結果是版本的發布節奏更快，因為更少的代碼需要被編譯和重新測試。編排框架例如Kubernetes通過自動化上線、容器滾動更新和必要時的回滾進一步加快了產品上市的節奏。
靈活性和可擴展性：整體架構的應用需要系統中的全部組件同時擴展。如果某個服務需要更高的性能，唯一的選項就是擴展系統中的所有服務而不是僅僅擴展需要擴容的單個服務。使用微服務，僅需要額外能力的單個服務需要擴容。擴容通過部署更多的容器來實現、可以實現更有效的容量計劃，更少的軟件授權和更低的總體擁有成本；因為服務和軟件可以更好的匹配。
彈性:整體架構應用的一個主要問題是當某個服務失效時可能整個系統可能都會受到連累. 在微服務中，各個服務之間的隔離性使得單個服務的失效不會擴展到系統的其它部分進而造成全局性的影響。如果使用容器，編排框架可以提供額外的彈性：當某個容器失效時，一個新的容器會被啟動，進而實現完全的冗余和容量。
組織架構匹配: 微服務可以更好的匹配組織架構，因為團隊的規模可以根據需要完成的任務進行更好的定義。團隊可以被分成更小的小組并專注在應用的某個組件上。這對分布在不同地理位置的團隊來講是非常有用的。例如，在新加坡的團隊處理三個服務，在舊金山的團隊處理五個服務，這兩個團隊可以獨立的發布和部署功能組件。 這可以幫助處理相同組件的不同職能的團隊（Ops，Dev，QA）打破疆界和更好的合作。這也可以保證不同團隊之間的溝通跟不同的服務之間的API相匹配。本質上來講，服務之間的API定義了不同開發團隊之間應該相互提供的服務的契約。
降低成本: 通過使用容器，應用和環境（設計，測試，生產，支持）可以共享相同的基礎設施,結果是更高的硬件利用率和由于管理簡化帶來的成本降低。另外，微服務也會降低技術方面的開銷。在整體化架構的應用中，重構一個大型應用的代碼會帶來開銷（時間，資源）。通過將應用分解成可以通過API訪問的微服務，代碼重構可以逐個服務進行，結果是更少的時間去維護和更新代碼。
這篇博文系列的第二部分，我們將討論如何用MongoDB構建微服務。
via： http://dockone.io/article/1290