參考：微服務架構與實踐 第二章

微服務架構的“微”應該遵循的兩個基本前提：

• 業務獨立性。應該保證微服務是具有業務獨立性的單元，並不能只是為了微而微。可以將某一領域的模型作為獨立的業務單元，譬如訂單、產品、合同等，也可以將某業務行為作為獨立的業務單元，譬如傳送郵件、單點登入驗證、不同資料庫之間的業務資料同步等。
• 團隊自主性。團隊的溝通及寫作成本。當團隊成員超過10人時，可以考慮劃分子團隊，讓不同的子團隊承擔獨立的責任。

單一職責原則，即一個物件應該只有一個發生變化的原因。對於每個服務而言，希望它處理的業務邏輯能夠單一，在服務架構層面遵循單一職責原則。也就是說，微服務架構中的每個服務，都是具有業務邏輯的，符合高內聚、低耦合以及單一職責的單元，不同的服務通過管道的方式靈活組合，從而構建出龐大的系統。

輕量級通訊，服務之間應通過輕量級的通訊機制，實現彼此間的互通互聯，互相協作。輕量級通訊機制，通常指語言無關、平臺無關的互動方式。對於輕量級通訊的格式而言，我們熟悉的XML或者JSON，它們的解析和使用基本與語言無關、平臺無關。對於輕量級的通訊的協議而言，通常基於HTTP，能讓服務間的通訊變得標準化並且無狀態化。目前，大家所熟悉的REST（Representational State Transfer），是實現服務之間互相協作的輕量級通訊機制之一。

對於常見的Java RMI或者.NET Remoting等，雖然這類機制能夠使用RPC的方式簡化消費者端的使用，使消費者一端像呼叫本地介面一樣呼叫遠端的介面，但其最大的劣勢在於：其對語言或者平臺有較強的耦合性，同時靈活性和擴充套件性較差。對於微服務而言，通過使用語言無關、平臺無關的輕量級通訊機制，使服務於服務之間的協作變得更加標準化，也就意味著在保持服務外部通訊機制輕量級的情況下，團隊可以選擇更適合的語言、工具或者平臺來開發服務本身。

獨立性，獨立性指在應用的交付過程中，開發、測試以及部署的獨立。在微服務架構中，每個服務都是一個獨立的業務單元，當對某個服務進行改變時，對其他的服務不會產生影響。換句話說，服務和服務之間是獨立的。

對於每個服務，都有獨立的程式碼庫，當對當前服務的程式碼進行修改後，並不會影響其他服務。從程式碼庫的層面而言，服務於服務是隔離的。對於每個服務，都有獨立的測試機制，並不比擔心破壞其他功能而需要建立大範圍的迴歸測試。也就是說，從測試的角度而言，服務和服務之間是鬆耦合的。

由於構建包是獨立的，部署流程也就能夠獨立，因此服務能夠執行在不同的程序中。從部署的角度考慮，服務和服務之間也是高度解耦的。

對於微服務架構中的每個服務而言，與其他服務高度解耦，只改變當前服務本身，就可以完成獨立的測試、構建以及部署等。

程序隔離，所有功能都執行在同一個程序中，也就意味著，當對應用進行部署時，必須停掉當前正在執行的應用，部署完成後，再重新啟動程序，無法做到獨立部署。如果當前某應用中包含定時任務的功能，則要考慮在什麼時間視窗適合部署，是否先停掉訊息佇列或者切斷與資料來源的聯絡，以防止資料被讀入應用程式記憶體，但還未處理完，應用就被停止而導致的資料不一致性。

在微服務架構中，應用程式由多個服務組成，每個服務都是一個具有高度自治的獨立業務實體。通常情況下，每個服務都能執行在一個獨立的作業系統程序中，這就意味著不同的服務能非常容易地被部署到不同的主機上。

容器虛擬化技術，Docker是一個開源的應用容器引擎，允許開發者將他們的應用以及依賴包打包到一個可移植的容器中，然後釋出到任何裝有Docker的Linux機器上。

同傳統的容器虛擬化技術相比，基於容器技術的Docker，不需要額外的hypervisor機制的支援，因此具有更高的效能和效率。另外，Docker的優勢也主要體現在以下幾個方面：

• 更快速地交付和部署，開發者可以使用一個標準的映象來構建映象，開發完成之後，運維人員可以直接使用這個映象來部署。
• 更輕鬆地遷移和擴充套件，Docker容器可以在任意平臺上執行，包括物理機、虛擬機器、公有云、私有云等。這種相容性可以低成本地將應用程式從一個平臺直接遷移到另一個。
• 更簡單地管理。使用Docker，所有映象的修改都能以增量的方式被分發和更新，從而實現自動化並且高效的管理。

Docker的出現，有效地解決了微服務架構下，服務力度細、服務數量多所導致的開發環境搭建、部署以及運維成本高的問題。同時，利用Docker的容器化技術，能夠實現一個節點上執行成百上千的Docker容器，每個容器都能獨立地執行一個服務，因此極大降低了隨著微服務數量增多所導致的節點數量增多的成本。

微服務的本質特徵通常包括如下幾個部分：

• 服務作為元件
• 圍繞業務組織團隊
• 關注產品而非專案
• 技術多樣性
• 業務資料獨立
• 基礎設施自動化
• 演進式架構

同共享庫相比，微服務是通過語言無關、平臺無關的輕量級通訊機制協作，因此靈活性非常高。當然，使用微服務也有它的不足之處，就是分散式呼叫比程序內呼叫更耗時間，並且嚴重依賴於網路的可靠性於穩定性。

業務資料獨立，傳統的單塊應用架構，傾向於採用統一的資料儲存平臺來儲存所有的資料。隨著業務的快速發展，需求的不斷變化，一方面，資料變得越來越複雜，難以管理，另一方面，隨著應用系統業務邏輯的不斷更新和發展，資料庫不僅承擔著資料儲存的作用，還承擔著不同系統之間的整合作用。

同時，傳統的資料庫大多是關係型資料庫，儲存的資料都是以結構化資訊為主，但隨著網際網路的快速發展，資料的結構並不具有確定性，或者說結構發生變化的頻率非常快，因此，對於如何有效維護業務資料，也成了一個難題，相應的維護成本會越來越高。

微服務架構，提倡服務自主管理其相關業務資料。這樣存在幾個非常明顯的優勢：

• 能夠隨著業務發展，提供業務資料介面整合，而不是以資料庫的方式同其他服務整合。
• 能夠隨著業務的發展，選擇更合適的工具管理過著遷移業務資料。

基礎設施自動化，微服務架構將應用程式本身分成多個小的服務，每個服務都是一個獨立的部署單元。因此，傳統只需要部署一次就能上線的單塊架構應用，採用微服務架構後，將需要對每個部分分別進行部署。另外，每個服務都需要部署帶來的健康監控、錯誤回滾、日誌分析等，成本也會顯著增加。換句話說，部署與運維的成本會隨著服務的增多呈指數級增長。因此在微服務的實踐過程中，對持續互動和部署流水線的要求較高。微服務的粒度越細，就意味著需要部署的業務單元越多，業務單元，就需要更穩定的基礎設定自動化機制，能夠建立執行環境，安裝以來，部署應用等。不過隨著雲技術的大規模推廣與使用，部署和運維的複雜度在大幅度降低。利用雲，可以快速建立系統所需要的資源，降低應用的部署成本。同時，由於持續整合、持續交付等實踐的深入人心，很多團隊都開始在構建軟體的過程中，使用持續交付提倡的基礎設施自動化技術。微服務的實踐將促使企業或者團隊不斷尋找更高效的方式完成基礎設施的自動化以及DevOps運維能力的提升。

演進式架構，微服務架構將一個複雜應用拆分成多個服務，每個服務都是一個獨立的、可部署的業務單元。同時，每個服務都能獨立執行在獨立的程序中，並且服務之間通過輕量級的通訊機制建立聯絡。從某種程度上而言，這些特點保證了在應用軟體隨著業務發展而不斷變化的過程中，企業或者組織能夠不斷調整軟體的架構，將不需要的服務（業務）拋棄，將需要的服務（業務）升級，並採用合適的技術或者工具不斷優化架構，保持其處於一個不斷演進的狀態。

微服務的優勢在於：獨立性、單一職責、技術多樣性。

微服務實施過程中需要考慮的因素包括：

• 分散式系統的複雜度
• 運維成本
• 部署自動化
• DevOps與組織架構
• 服務間依賴
• 服務間依賴管理

分散式系統的複雜度主要包括以下幾點：

效能。同傳統的單塊架構相比，分散式系統由於元件與元件的呼叫時跨程序、跨網路的呼叫，因此，必然要考慮網路延遲以及寬頻的影響。尤其要考慮，當某業務場景需要多個服務相互協作時，響應時間以及效能對系統的影響。

可靠性。在分散式系統中，由於網路、頻寬、節點自身的可靠性等因素，然和一次元件間的遠端呼叫都有可能失敗。而且，隨著微服務數量的增多，還會出現更多的潛在故障點。因此，如何提高系統的可靠性，降低由於網路、元件等引起的單點故障率，也增加了系統構建的挑戰。

非同步。對於跨網路的呼叫，需要考慮非同步的通訊機制。同步通訊的過程一般是傳送請求，接收相應並處理，整個過程實現簡單，但會造成阻塞。非同步通訊的過程則是傳送請求立即返回，不會造成阻塞，一般適用於耗時操作的處理。但非同步通訊在享受非阻塞的優勢的同時，也大大增加了功能實現的複雜度，並且當出現缺陷時，定位問題、除錯問題的難度也更大。

資料一致性。在分散式系統中，為了保證資料的一致性，通常我們會考慮使用分散式業務管理。但由於分散式事務管理需要跨多個節點來保證資料的瞬時一致性，因此比起傳統的單塊架構的事務，成本要高的多。另外，在分散式系統中，通常也會考慮通過資料的最終一致性來解決資料瞬時一直帶來的系統不可用。

通常所說的運維成本主要包括以下幾個方面：

配置：主要包括應用相關的配置資訊，譬如引數、依賴部分、資料庫地址、快取地址等

部署：主要包括將應用部署到指定的環境中

監控與告警：主要包括對應用的健康狀況進行監控，並當發現故障時能及時告警

日誌收集：主要包括日誌收集，並提供搜尋等方式，幫助團隊日誌快速定位問題

相比傳統的單塊架構應用，微服務將系統分成多個獨立的部分，每個部分都是可以獨立部署的業務單元。這就意味著，原來適用於單塊架構的集中式的部署、配置、監控或者日誌收集等方式，在微服務架構下，隨著服務數量的增多，每個服務都需要獨立的配置、部署、監控、日誌收集等，因此成本呈指數級增長。

如何有效地構建自動化部署流水線，降低部署成本、提高部署頻率，是微服務架構下需要面臨的一個挑戰。

微服務不僅表現出一種架構模型，同樣也表現出一種組織模型。這種新型的組織模型意味著開發人員和運維的角色發生的變化，開發者將承擔起服務整個生命週期的責任，包括部署和監控，而運維也越來越多地表現出一種顧問式的角色，儘早考慮服務如何部署。

因此，如何在微服務的實施中，按需調整組織架構，構建全功能的團隊是一個不小的挑戰。

在服務數量逐漸增多的情況下，如何有效地保證服務之間能夠有效按照介面的約定正常工作，成為微服務實施過程，測試面臨的主要挑戰。