現今微服務在系統複雜度日益提升的企業中非常流行。目標是讓每個微服務處理單一特定工作，並將其處理好。這通常能帶來易於維護服務、隔離錯誤以及提升服務可靠性和可擴展性的好處。
採用微服務的好處顯而易見。
- 可維護性。解耦功能，以便每個功能可以單獨維護，從而降低因其他與此功能無關的程式碼錯誤而導致問題的風險。應用程式團隊可以專注於特定範圍，輕鬆維護。
- 易於部署。如果專案非常龐大，並且有許多開發人員貢獻程式碼到相同的服務，部署和回滾服務將會很麻煩，因為出現錯誤的機率更高，有時某些開發人員的更改必須納入，但由於其他開發人員程式碼中的錯誤而必須回滾。微服務模型可以在一定程度上減少此類麻煩。
- 技術棧選擇的靈活性。由於每個微服務都是一個獨立的功能，並單獨託管。每個服務的技術棧可以不同。這意味著每個服務團隊都可以選擇最適合服務且團隊熟悉的技術棧。可以是 GoLang、Java 或 Python 等。
- 易於擴展。如果服務流量突然激增，可以快速啟動服務執行個體，因為它不會太重，不需要啟動太多程序。
- 易於遷移。如果某些功能可以用其他服務替換，則只需要上游或下游系統連接到新服務，并在遷移完成後移除舊服務。
然而，任何事物都有兩面性，除了這些好處之外，如果在實際專案中處理不當，微服務也會給公司帶來問題。
以下是如果微服務採用不當可能導致的一些問題。
- 可維護性。每引入一個新的微服務，就需要設置和維護一套新的基礎設施（伺服器執行個體、網路連接、安全組等）。這些配置需要良好維護，尤其是在雲端環境中。這增加了 SRE 的挑戰。
- 可擴展性。當需要進行任何升級或修補程式時，SRE 需要對每個服務的所有執行個體進行額外的工作。當規模變大時，這將會過於繁重。
- 可用性。每個服務都通過 HTTP 或 RPC 通訊，因此對網路連接有很高的要求，如果網路連接不穩定，將會造成麻煩，從而導致延遲增加。
- 依賴性。如果設計不當，將會導致依賴性問題，其中一個服務必須在另一個服務部署後才能部署，因為兩個服務之間會新增和共享一些內容。
- 一致性。在分散式環境中，每個服務都負責自己的職責。如果某些功能需要整體完成，則需要一個協調器。在這種情況下，維護狀態一致性的難度會增加，如果一個服務未能完成某些請求，則需要通知所有其他服務並相應地回滾。
- 技術複雜性。如優點部分所述，每個服務都可以擁有自己的技術棧。缺點是這不利於人們在服務之間移動。有些人可能不了解其他服務使用的語言，當他轉到其他團隊或接管其他服務時，學習曲線會增加，從而減慢轉換速度。
每當要引入新功能時，請謹慎考慮是否需要新的微服務。下面記錄了一些通用建議。
- 嘗試建立關於創建新微服務的標準模板。這應該包括為什麼需要新服務、使用的技術棧、服務如何與其他服務互動等等。並且需要由來自不同團隊的一組人審查，以確定是否應該創建新服務。
- 需要提供一個工具或流程，以便可以輕鬆設置新服務，而無需服務團隊手動設置所有內容（伺服器執行個體、資料庫、快取、api-gateway 等）。
- 在微服務中使用通用的技術棧，以便於管理和在公司內部移動。
