作者：Janet Wagner
近年來，微服務作為一種大規模建構可靠應用程式的方法越來越受歡迎。而且像 Amazon、Microsoft 和 Netflix 等大型公司，談論微服務也已經有一段時間了。這篇文章探討了微服務的策略，特別是從單體式架構開始，之後再轉向微服務，以及一開始就直接使用微服務。
什麼是單體式架構？
當開發人員談論單體式應用程式時，他們通常指的是被視為單一單元、緊密耦合，且通常需要一次性部署到單一伺服器的應用程式。單體式應用程式也作為單一單元進行擴充，可能共用一個資料庫 (通常是關聯式的)，並且通常整個應用程式都只有一個龐大的程式碼庫。所有內容都在程式碼庫中定義，例如前端和伺服器端邏輯等，並且通常只使用一小組語言來建構應用程式。在某些情況下，單體式應用程式可以部署到多個伺服器，但該應用程式仍會被視為一個單元。
什麼是微服務？
微服務在應用程式開發人員之間引起了很多討論，但是對於微服務的定義，業界並沒有達成共識。微服務更像是一種開發分散式應用程式的概念。但是，許多業界領導者對於微服務的特性已達成共識。在這些特性中，服務是鬆散耦合的，但受限於上下文、可以獨立於彼此部署和擴充，並且使用輕量級機制 (例如 HTTP、REST API、WebSocket) 進行通訊。Sam Newman 在 「Building Microservices」一書中提供了簡短的定義：「微服務是小型、自主的服務，它們協同工作。」
建構您的應用程式 — 先採用單體式架構還是微服務？
當涉及到微服務和 API 的策略時，這很大程度上取決於您決定先採用單體式應用程式，然後再轉向微服務，還是一開始就直接使用微服務。
業界領導者對於先採用單體式架構還是微服務有不同的見解。Martin Fowler 是一位著名的作家、軟體工程師和 ThoughtWorks 的首席科學家，他提倡先採用單體式架構的方法。他建議最好先從單體式架構開始，然後在需要時再轉向微服務。innoQ 的共同創辦人兼首席顧問 Stefan Tilkov 提倡先採用微服務的方法，理由是單體式架構的組件最終會彼此緊密耦合。這使得之後很難將單體式架構拆分成單獨的服務。
應該注意的是，應用程式開發有很多種方法，不僅僅是二選一 - 先採用單體式架構還是微服務。例如，Gamut 平台資深工程主管 Darby Frey 在 Medium 上的一篇文章中解釋說，他的團隊決定不先做單體式架構或微服務。該團隊反而建構了兩個應用程式 - 不是真正的微服務，也不是單體式架構。該團隊建構的架構包含一個 API 閘道層，使他們可以擁有任意數量的後端服務。
在為您的應用程式選擇架構之前，需要考慮很多因素。如果您的開發團隊沒有任何建構微服務的經驗，那麼單體式架構可能是更好的選擇。如果您希望應用程式的功能是最先進的，那麼您需要為每個功能使用最好的語言、框架和函式庫。在這種情況下，微服務將是更好的選擇。這並不是說您不能使用最先進的功能來建構單體式架構。但是單體式架構往往僅限於幾種語言，這意味著您最終可能會使用並非最適合您應用程式所有功能的語言來建構功能。
從單體式架構開始
您會想要從單體式架構開始的一些原因是什麼？與微服務相比，部署單體式架構通常更容易，因為它通常是在一個伺服器上進行一次部署。而且由於該應用程式被視為單一單元，因此更容易監控和執行端對端測試。與單體式應用程式相比，監控和測試分散式應用程式更加困難，因為服務通常具有不同的執行階段環境。此外，當需要測試一項服務時，也需要啟動該服務所依賴的所有其他服務。
那麼，為什麼您不想從單體式架構開始呢？您可能不想從單體式架構開始的最大原因之一是單體式架構最終會出現許多緊密耦合的組件。這使得擴充和維護程式碼變得非常困難。另一個原因是，由於所有緊密耦合的組件，程式碼庫通常最終變得難以理解，這使得新開發人員難以上手。
從微服務開始
您會想要從微服務開始的一些原因是什麼？由於微服務是自主的，因此可以獨立且快速地開發、部署、測試和擴充服務。也可以使用任何語言開發服務，這意味著開發人員可以試用新技術並新增功能，而不會干擾應用程式的其他部分。而且如果一項服務出現問題，其他服務很可能會保持正常運行。由於一項甚至多項服務出現問題而導致應用程式當機的風險顯著降低。
API 佈道師 Kin Lane 對於設計微服務有一個有趣的看法，即在編寫任何程式碼之前，可以使用 OpenAPI 規格來敲定微服務的所有組件。可以使用 OpenAPI 和 與 OpenAPI 相關的工具來產生文件、服務的模擬表示、探索機制和許多其他微服務組件。
那麼，為什麼您不想從微服務開始呢？您可能不想從微服務開始的原因之一是，當建構微服務時，跨領域問題往往會出現。當涉及到微服務時，安全性以及諸如記錄、快取和授權等跨領域問題很難解決，而且通常需要大量的開發工作。一些公司會使用 API 閘道，以便在集中式位置實作跨領域問題和安全性。
從微服務開始可能不是最佳選擇的另一個原因是，如果您的團隊沒有足夠的微服務建構經驗。微服務架構本質上很複雜，因此如果您的團隊沒有建構微服務的經驗，則建構微服務是存在風險的。
微服務之間的通訊
微服務是自主的服務，採用此類型架構的應用程式通常有數十個，有時甚至數百個服務。這些服務需要能夠彼此之間以及與用戶端之間進行通訊。微服務通常使用容器部署，這些容器使用跨程序通訊 (IPC) 機制來彼此互動。IPC 機制最常見的通訊方法 (特別是如果涉及請求-回應週期) 是 RESTful。這通常意味著使用 HTTP/JSON API。
規劃通訊策略至關重要，因為服務必須能夠高效且可靠地進行通訊。服務之間的通訊存在許多挑戰，例如延遲、失敗和路由。Red Hat 雲端應用程式開發首席架構師 Christian Posta 在最近的文章中談到，呼叫服務和讓服務彼此通訊是開發微服務最困難的部分之一。
選擇最適合您應用程式的方法
微服務是一種流行的應用程式開發方法，因為它可以讓開發人員建構快速、可靠且高度可擴充的應用程式。但是，分散式應用程式往往非常複雜。只有在該方法最適合您的應用程式時，才選擇微服務。
感謝您的閱讀！想尋找更多 API 資源嗎？訂閱 Swagger 電子報。每月接收包含我們精選 API 文章、培訓、教學等內容的電子郵件。訂閱