在這一系列文章中，我們將從架構、設計等不同方面來探討，在雲的可移植性方面，具體都需要考慮哪些細節問題，如何最大限度避免雲時代的技術釘選，充分發揮雲的靈活性優勢。
下文將簡要探討雲原生和容器技術。歡迎點選這裏回顧上篇內容，了解雲原生和容器技術在雲可移植性方面的註意事項。
微服務應該是可延伸的，並且是專註於單一職能的，由每個自包含的模組化單元負責處理一個更大規模系統中的一個特定功能，而大型應用程式往往就可以由這種模組化的元件或服務（如容器或無伺服器計算）構建而成。
我們可以將微服務看作由不同部門、預算和要求組成的業務。每年，這些要求都會根據公司需求的變化而變。隨著時間推移，我們的應用程式也會面對不斷變化的要求，其中的某些方面可能會產生更多需求，有些方面則需要我們投入更多關註。此外，應用程式中的不同方面可能還需要進行不同程度的擴充套件或縮放。微服務可以幫助我們在不影響其他方面的情況下，以獨立的方式對應用程式中的某些方面進行縮放或擴充套件。
相信大家都還記得編程領域所謂的「單一職責原則」（Single responsibility principle）。微服務在這方面也是一樣的。微服務應該只負責做一件事，並且做好這件事。當然，透過使用微服務，我們還能在彈性和容錯能力方面獲得一些固有的好處。微服務架構旨在透過將故障約束到單個服務來防止出現影響整個系統的故障。如果出現特定故障，我們將知道故障位於哪裏，並能在不影響其他東西的情況下解決這種故障。
另外還要註意可發現（Discoverable）問題。透過使用諸如HashiCorp的Consul這種服務網路解決方案，我們將能知道新服務何時上線，並能使用一個集中的系統充當服務目錄，從而定義這些服務的用途以及服務之間的通訊方式。
為何使用微服務
微服務最佳實踐
保持微服務規模小巧、專註於負責單一業務能力，這一點至關重要。這樣我們才能輕松添加額外的功能並避免蔓延。然而，每個微服務的理想規模是多少，這並沒有什麽明確標準，這需要我們根據具體套用及實際需求來決定。
我們還需要針對失敗進行相關設計。雖然多個服務和微服務執行過程中，按照設計本身就具備與生俱來的容錯能力，但額外的設計可以增加額外的彈性，例如重試機制、斷路器以及隔板。想象一下船舶為什麽會安裝隔板。這些隔板可以保證船舶的結構完整性，而如果船艙漏水，隔板關閉，也可以保證船不會沈沒。很多基於事件驅動的架構使用了一種所謂的死信佇列（Dead letter queue），如果某條訊息無法傳遞，就會被放入一個特殊的佇列，接下來就可以檢查該佇列中的訊息來確定失敗原因。
微服務應該圍繞領域驅動（Domain-driven）的設計原則來設計，這意味著要基於業務能力對服務建模，並使用通用語言來保障服務符合業務需求。領域驅動的設計側重於圍繞對業務的深入理解來打造軟體系統，其原則有助於指導設計過程，確保軟體與領域保持一致且能為業務提供價值。這些原則共同促進了對業務領域的深入理解，有助於確保開發工作能與業務需求和不斷變化的要求緊密契合。
采取以API為先的方法進行設計並實作API閘道器，借此即可提供中央連線點，從而促進微服務和第三方子系統之間的通訊。API閘道器負責處理大部份路由工作，以及身份驗證、認證、速率限制等工作。API的設計模式對於微服務的模組化和可復用能力至關重要。
此外對於微服務，還有下列這些最佳實踐：
歡迎關註Akamai知乎機構號 ，第一時間了解高可用的MySQL/MariaDB參考架構，以及豐富的應用程式範例。
