作為軟體開發人員，我們已知道思考如何將應用程式因數分解成組件部分。 這是對象導向、軟體抽象和組件化的中心模式。 現在，這種因數分解往往以共用庫和技術層之間的類與介面呈現。 通常採用一種分層方法，有後端存儲、中間層業務邏輯和前端用戶界面 (UI)。 過去幾年來的變化是身為開發人員的我們，開始為業務驅動 ...
作為軟體開發人員，我們已知道思考如何將應用程式因數分解成組件部分。 這是對象導向、軟體抽象和組件化的中心模式。 現在，這種因數分解往往以共用庫和技術層之間的類與介面呈現。 通常採用一種分層方法，有後端存儲、中間層業務邏輯和前端用戶界面 (UI)。 過去幾年來的變化是身為開發人員的我們，開始為業務驅動的雲構建分散式應用程式。
不斷變化的業務需求包括：
- 為吸引新地理區域的客戶而大規模構建和操作的一項服務（舉例而言）；
- 更快速地提供特性與功能，靈活應對客戶的需求；
- 提高資源利用率以降低成本；
這些業務要求影響我們如何構建應用程式。
有關 Azure 實現微服務的方法的詳細信息，請閱讀微服務：由雲支持的應用程式革新。
單一式設計方法與微服務設計方法
所有應用程式會隨著時間而發展。 成功的應用程式因為有實用性而發展。 失敗的應用程式不會發展，最終會被取代。 問題在於現在對要求瞭解多少，以及未來有何變化？ 例如，如果要為某個部門構建報告應用程式。 可以確定的是，應用程式保留在公司範圍內，而且報表的生存期非常短。 那麼，選擇的方法將不同於構建服務向數千萬個客戶傳送視頻內容的方式。
在已知以後可以重新設計應用程式的情況下，有時向外尋求概念證明才是驅動因素。 過度設計永不使用的功能並沒有太大意義。 這就是通常所謂的工程取捨。 另一方面，公司談論構建雲時都期望成長和使用量。 問題在於成長和規模不可預測。 我們想要能夠快速創建原型，同時還要瞭解我們正在通往未來成功的路上。 這是簡練的啟動方法：構建、測量、學習和迭代。
在客戶端-伺服器時代，我們傾向專註於構建分層式應用程式，每一層採用特定的技術。 已針對這些方法派生出“單一式”應用程式一詞。 介面通常存在於各層之間，而在一層內的各組件之間採用更緊密耦合的設計。 開發人員設計並分解已編譯為庫並鏈接為一些可執行文件和 DLL 的類。
這類單一式設計方法有一些優點。 設計較簡單，組件之間通常通過進程間通信 (IPC) 調用，因此調用更快。 此外，每個人都只測試單一產品，人力資源運用更有效率。 缺點是分層之間緊密耦合，無法縮放單個組件。 如果需要執行修複或升級，則必須等待其他人完成其測試， 因此更難以發揮靈活性。
微服務解決了這些缺點，更密切配合上述業務要求，但它們本身也都有優缺點。 微服務的優點是通常各自封裝較為簡單的業務功能，可獨立增加或減少、測試、部署和管理。 微服務方法的一個重要優點是團隊傾向於以業務方案為導向，而不是以分層方法建議的技術為導向。 實際上，較小的團隊可以根據客戶方案來開發微服務，並採用他們選擇的任何技術。
換句話說，組織不需要為了維護微服務應用程式而將技術標準化。 擁有服務的單個團隊可以根據團隊的專業知識，或什麼最適合解決問題，各自發揮所長。 實際上，最好有一組建議的技術，例如特定的 NoSQL 存儲或 Web 應用程式框架。
微服務的缺點包括需要管理越來越多的獨立實體、處理更複雜的部署和版本控制。 微服務之間的網路流量以及相應的網路延遲不斷增加。 經過大量的討論之後，粒度服務是性能瓶頸的解決良方。 如果沒有工具幫助查看這些依賴性，很難“看到”整個系統。
標準通過在通信方式上達成共識，以及只關註需要從服務獲得什麼來使微服務方法奏效，而不是僵化的約定。 必須在設計的初期定義這些約定，因為之後服務將各自獨立更新。 在設計微服務方法時出現的另一個描述是“面向服務的精細體繫結構 (SOA)”。
簡而言之，微服務設計方法是分離的服務聯合，各自獨立更改，並達成一致的通信標準。
隨著越來越多雲應用的生成，人們發現從長遠來看，這種將整體應用分解成獨立、方案焦點式服務的做法是較好的方法。
應用程式開發方法的比較
1) 單一式應用包含域特定的功能，通常按照功能層來劃分，例如 Web、業務和數據。
2) 單一式應用可通過複製到多個伺服器/虛擬機/容器上進行擴展。
3) 微服務應用程式將單個功能分隔成單個較小的服務。
4) 微服務方法可通過獨立部署每個服務而擴展，跨伺服器/虛擬機/容器創建這些服務的實例。
使用微服務方法進行設計並非所有項目的靈丹妙藥，但確實更符合前面所述的業務目標。 如果確定以後有機會根據微服務設計重寫代碼，可以從單一式方法入手。 更常見的是，從單一式應用程式入手，分階段慢慢分解它（從需要提高可縮放性或敏捷性的功能區域開始）。
總而言之，微服務方法是以許多小服務來組成應用程式。 這些服務在部署於一組電腦上的容器中運行。 較小的團隊可針對方案來開發服務，且每個服務獨立進行測試、版本控制、部署和縮放，因此整個應用程式可以得到發展。
什麼是微服務？
微服務存在多種定義。 如果搜索 Internet，會發現許多有用的資源，這些資源提供了自己的觀點和定義。 但在微服務的以下大部分特性上，已廣泛達成共識：
- 封裝客戶方案或業務方案。 要解決什麼問題？
- 由小型工程團隊開發。
- 使用任何編程語言編寫並使用任何框架。
- 由獨立控製版本、部署及縮放的代碼和（可選）狀態組成。
- 通過定義完善的介面和協議來與其他微服務交互。
- 具有用來解析位置的唯一名稱 (URL)。
- 在出現故障時可保持一致且可用。
一言以蔽之：
微服務應用程式由獨立控製版本和可縮放的、以客戶為中心的服務組成，這些服務通過標準協議和定義完善的介面彼此通信。
我們在上一部分已介紹了前兩點，接下來進一步澄清其他各要點。
使用任何編程語言編寫並使用任何框架
作為開發人員，我們應該根據本身的技能或服務需求，自由選擇所需的語言或框架。 在某些服務中，可能認為 C++ 的性能優點勝於一切， 而在其他服務中，C# 或 Java 的簡易管理開發可能才是最重要的。 在某些情況下，可能需要使用特定合作伙伴庫、數據存儲技術，或向客戶端公開服務的方式。
選擇技術之後，接下來的課題就是服務的操作或生命周期管理和縮放。
允許獨立控製版本、部署及縮放的代碼和狀態
無論選擇何種方式來編寫微服務，代碼和（可選）狀態都應該獨立部署、升級和縮放。 這確實是難以解決的問題之一，因為這涉及到所選的技術。 在縮放方面，難以瞭解如何分區（或分片）代碼和狀態。 當代碼和狀態使用不同的技術時（目前的普遍情況），微服務的部署腳本必須能夠妥善縮放兩者。 這也關乎到靈活性和彈性，以便可以升級某些微服務，而無需一次性全部升級。
暫時回到單一式方法和微服務方法的比較，下圖顯示了狀態存儲方法的差異。
應用程式樣式之間的狀態存儲
左側的單一式方法具有單一資料庫和多層的特定技術。
右側的微服務方法顯示互連的微服務圖，其中狀態通常以微服務為範圍，並使用各種技術。
在單一式方法中，應用程式通常使用單一資料庫。 優點是這是單一位置，很容易部署。 每個組件可以通過單個表來存儲其狀態。 困難之處在於團隊必須嚴格區分狀態。 無可避免地就想將新的列添加到現有客戶表、在表之間執行聯接，並且對存儲層形成依賴性。 發生這種情況後，無法縮放各個組件。
在微服務方法中，每個服務都管理並存儲自己的狀態。 每個服務將負責同時縮放代碼和狀態，以滿足服務的需求。 不足的是，需要創建應用程式數據的視圖或查詢時，必須跨不同的狀態存儲進行查詢。 為瞭解決此問題，通常由一個獨立的微服務構建一個跨許多微服務的視圖。 如果需要對數據執行多個即席查詢，每個微服務應該考慮將其數據寫入數據倉庫服務以供離線分析。
版本控制特定於部署的微服務版本，以便能夠部署和並行運行多個不同的版本。 當較新版的微服務在升級期間失敗，因而需要回滾到舊版時，版本控制可以解決這種情況。 版本控制的另一種情況是執行 A/B 式測試，其中不同的用戶將體驗到不同版本的服務。 例如，在更廣泛推出新功能之前，通常先對一組特定的客戶升級微服務以測試新功能。 在微服務的生命周期管理之後，便可以在微服務之間的通信。
通過定義完善的介面和協議來與其他微服務交互
本主題無需花費太多時間，因為過去 10 年來發佈的大量關於面向服務的體繫結構的文獻對通信模式進行了介紹。 一般而言，服務通信使用 REST 方法，並配合 HTTP 與 TCP 協議及 XML 或 JSON 作為序列化格式。 從介面觀點來看，這涉及到採用 Web 設計方法。 但仍可以使用二進位協議或自己的數據格式。 如果這些協議和格式非公開可用，微服務使用起來就很難，因此要有心理準備。
具有用來解析位置的唯一名稱 (URL)
記得我們一直在說，微服務與 Web 有點類似嗎？ 就像 Web 一樣，微服務無論在何處運行，都必須可定址。 若要在電腦上運行特定微服務，很快就會陷入困境。
就像 DNS 解析特定電腦的特定 URL 一樣，微服務需要有唯一的名稱來發現它目前所在的位置。 微服務需要有可定址的名稱才能獨立於它們運行所在的基礎結構之外。 這意味著服務的部署和發現方式之間互相影響，因為需要有服務註冊表。 同樣地，當電腦發生故障時，註冊服務必須指出服務現在的運行位置。
接下來的主題：複原能力和一致性。
在出現故障時可保持一致且可用
處理意外的故障是最難解決的問題之一，特別是在分散式系統中。 開發人員編寫的代碼大多是在處理異常，這也是測試時花費最多時間的地方。 問題比編寫代碼來處理故障更複雜。 當運行微服務的電腦發生故障時，該怎麼辦？ 不僅需要檢測這種微服務故障（本身就是棘手的問題），還需要設法重新啟動微服務。
微服務必須能夠從故障複原，出於可用性理由，通常還必須能夠在另一臺電腦上重新啟動。 這也涉及到代表微服務存儲的狀態、微服務可從何處恢復此狀態，以及微服務是否能夠成功重新啟動它。 換句話說，需要能夠複原計算（也就是重新啟動進程）以及狀態或數據（不丟失任何數據，數據保持一致）。
在其他情況下，複原能力的問題更難處理，例如應用程式升級期間失敗。 在配合部署系統一起運行時，微服務不僅需要恢復。 它還需要確定是要繼續升級到更新版本，還是回滾到舊版以維持一致的狀態。 需要考慮一些問題，例如，是否有足夠的電腦可用於繼續升級，以及如何恢複舊版的微服務。 需要微服務發出運行狀況信息才能做出這些決定。
報告運行狀況和診斷
微服務必須報告其運行狀況和診斷，這一點看似明顯，但卻經常被忽視。 否則，難以從操作觀點上深入瞭解。 面臨的難題是關聯一組獨立服務的診斷事件並修正電腦時鐘偏差以識別事件順序。 同樣地，通過議定的協議和數據格式來與微服務交互時，需要將運行狀況和診斷事件的記錄方式標準化，這些事件最終將寫入可供查詢和查看的事件存儲。 在微服務方法中，關鍵在於不同團隊同意採用單一記錄格式。 需要有一致的方法來查看整個應用程式中的診斷事件。
運行狀況與診斷不同。 運行狀況是指微服務報告其當前狀態，以便採取適當的措施。 一個很好的例子便是使用升級和部署機制來保持可用性。 雖然當前服務可能由於進程崩潰或電腦重新啟動而狀況不正常，但服務可能仍可運行。 不應該執行升級而讓情況惡化。 最好是先進行調查，或讓微服務有時間恢復。 微服務中的運行狀況事件可以幫助我們制定明智的決策，並且實際上也有助於創建自愈服務。
Service Fabric 作為微服務平臺
Microsoft 從提供盒裝產品（通常是單一式）轉換到提供服務後，Azure Service Fabric 橫空問世。 構建和運營 Azure SQL 資料庫和 Azure Cosmos DB 等大型服務的經驗造就了 Service Fabric。 該平臺隨著越來越多服務採用它而不斷發展變化。 重要的是，Service Fabric 不僅要在 Azure 中運行，還要在獨立的 Windows Server 部署中運行。
Service Fabric 旨在解決構建和運行服務方面的難題，並有效地利用基礎結構資源，使團隊可以使用微服務方法來解決業務問題。
Service Fabric 提供三大廣泛領域，有助於用戶使用微服務方法生成應用程式：
- 提供系統服務的平臺，用於部署、升級、檢測和重啟失敗的服務、發現服務、路由消息、管理狀態和監視運行狀況。 這些系統服務實際上具備上述微服務的許多特性。
- 能夠部署在容器中運行或作為進程運行的應用程式。 Service Fabric 是容器和進程 Orchestrator。
- 有助於以微服務形式生成應用程式的生產編程 API：ASP.NET Core、Reliable Actors 和 Reliable Services。 可以選擇使用任意代碼來生成微服務。 但使用這些 API 不僅可讓作業變得更簡單，也能更深入地與平臺集成。 例如，可以獲取運行狀況和診斷信息，或利用內置的高可用性。
Service Fabric 與服務生成方式無關，可以使用任意技術。不過，它確實提供內置編程 API，以便用戶可以更輕鬆地生成微服務。
將現有應用程式遷移到 Service Fabric
Service Fabric 的關鍵方法是重用現有代碼，可以通過新的微服務對現有代碼進行現代化。 應用程式現代化分為五個階段，可以在任意階段開始和停止操作。 具體包括：
1) 採用傳統的單一式應用程式
2) 直接遷移 - 使用容器或來賓可執行文件在 Service Fabric 中托管現有代碼。
3) 現代化 - 將新微服務與現有容器化代碼一起添加。
4) 創新 - 完全根據需求，將單一式應用程式分解成微服務。
5) 轉換為微服務 - 轉換現有的單一式應用程式，或生成新領域應用程式。
有必要再次強調，可以在其中任一階段啟動和停止。 並不強求繼續執行到下一階段。 現在，讓我們來看看每個階段的示例。
直接遷移 - 許多公司都出於兩個原因，將現有單一式應用程式直接遷移到容器中；
- 由於整合和移除現有硬體或以較高密度運行的應用程式，因此成本降低。
- 開發和運營遵循一致的部署協定。
成本降低可以理解，在 Microsoft 內部，大量現有應用程式正在進行容器化，節省的成本就高達數百萬美元。 雖然部署一致性難以評估，但同樣很重要。 也就是說，開發者仍可以自由選擇適合自己的技術；不過，運營人員只接受使用一種方法來部署和管理這些應用程式。 這樣可以減輕運營壓力，不必處理許多不同的複雜技術，也不用強制開發者只選擇特定技術。 實質上，每個應用程式都容器化到獨立式部署映像中。
許多組織止步於這一階段。 它們已享受到容器帶來的優勢，Service Fabric 能夠提供完整的管理體驗，包括部署、升級、版本控制、回滾、運行狀況監視等。
現代化 - 將新服務與現有容器化代碼一起添加。 若要編寫新代碼，最好決定在微服務之旅上略進幾步。 可以是添加新的 REST API 終結點，也可以是添加新的業務邏輯。 這樣，便可以開始生成新的微服務，併進行開發和部署。
創新 - 還記得本文開頭提及的推動微服務方法發展且不斷變化的原始業務需求嗎？ 在此階段，需要確定當前應用程式是否存在這種情況。如果存在，需要開始分解單一式應用程式或進行創新。 例如，由於被用作工作流隊列，資料庫在處理方面成為瓶頸。 隨著工作流請求數量不斷增加，需要分佈工作，以實現縮放。 因此，對於不縮放或需要頻繁更新的特定應用程式部分，將其分解為微服務，併進行創新。
轉換為微服務 - 在此階段，應用程式完全由微服務組成或分解為微服務。 到此，已完成微服務之旅。 雖然可以從此階段開始，但如果沒有微服務平臺提供幫助，這會是一項巨額投資。
微服務適合我的應用程式嗎？
也許。 根據我們的經驗，隨著 Microsoft 中越來越多團隊開始出於商業理由而以雲為目標來構建，有許多團隊都瞭解到採用類似微服務的方法所帶來的優點。 例如，多年以來，必應一直在搜索方面開發微服務。 微服務方法對於其他團隊而言相當新穎。 團隊發現需要解決一些疑難問題，但這並非他們的強項。 這就是為什麼 Service Fabric 受到重視而成為構建服務的最佳技術。
Service Fabric 的目標是將使用微服務方法構建應用程式時的複雜性降低，使不需要經歷許多耗費成本的重新設計工作。 從小規模開始，需要時縮放，淘汰服務，添加新服務，隨客戶使用而改進才是應對之道。 我們也知道，為了讓微服務更易於為大部分開發人員所接受，還有許多其他尚待解決的問題。 容器和執行組件編程模型都是朝此目標前進的一小步，我們確信將涌現出更多的創新來輕鬆實現目標。
