原文連結

在開發軟體的時候，既要考慮程式碼的實現也要考慮架構。當以一種邏輯上有意義的方式進行開發的時候，開發會更為有效。除了架構，軟體也需要考慮使用者互動，以及介面。

API與微服務都牽涉到結構與互動。微服務可能會被誤解為僅僅是在一個端點上提供一個API。事實上，微服務包含了更多的彈性與功能性。這篇文章會淺析API與微服務的不同，以及微服務能夠提供的好處。

開始之前，先看一些定義。

什麼是API

首先，讓我們看看什麼是API。根據維基百科，API是一系列子程式定義，通訊協議，以及建立軟體的工具。通常情況下，它是一系列定義清晰的方法用於在多個元件之間進行通訊。

簡單來說，可以將API看做是一個契約，通過一個契約你可以請求一個特定的服務。如今，API大量運用於Web應用，例如社交媒體，銀行軟體等等。標準的契約讓外部程式可以進行互動。

現在，假設你要開發一個與Facebook互動的應用程式。你需要使用Facebook Graph API獲取資料，例如使用者，釋出內容，評論等。API簡化了使用資料的複雜度並提供了易用的方式讓開發者獲取資料。

通常的API方法

如今，API通常都以RESTful風格開發。這些API有一系列與HTTP相關的動詞，例如：

• GET
• POST
• PUT
• DELETE

這種一致性的好處是在執行各種操作時有一個統一的標準。四種不同的HTTP動詞與CRUD相對應。當在一個應用程式中處理不同的API時，這有助於理解不同操作的含義。

好了，關於API我們就講這麼多，下面讓我們看看微服務吧。

什麼是微服務

維基百科這麼定義微服務： 一種軟體開發技術——面向服務架構的變體，以一系列鬆耦合的服務組織一個應用程式。在微服務架構中，服務是細粒度的且協議是輕量級的。

在我們深入瞭解什麼是微服務之前，讓我們看看Monolith。理解微服務與Monolith之間的差別有助於你更好地理解微服務的好處。

微服務的祖先：Monoliths

在早前的軟體開發中（以及當前的許多企業環境中），誕生了Monolith的概念。Monolith是一個應用程式，包含了完整的功能集合，在一個地方提供服務，並儲存所有內容。它看起來就像這樣：

所有的應用程式元件位於一個地方，包括UI層，業務邏輯層，以及資料訪問層。以Monolith方式開發程式是一個簡單自然的過程，大部分專案都以這種方式開始。但是新增功能導致了大小與複雜度的增加，隨著時間的增加monolith的不斷變大帶來了很多缺點，包括：

• 有導致大泥球模式與反面模式的風險
• 技術棧收到限制。特別是當應用程式變大以後，轉向不同的技術棧變得越來越困難，即使之前的技術被認為不再是最好的選擇。
• 修改資料庫會影響整個應用程式。例如，如果僅僅是一個業務邏輯需要經常改動，也會迫使重新發布整個應用程式，不僅浪費時間還要承擔更多風險。

因此，替代方案就是將monolith分離成微服務。

微服務

讓我們將上面的例子轉為微服務，程式的架構將像下面這樣：

這個重構中有幾個要點：

• 業務邏輯的細分部分，每個都圍繞著一個微服務。整個應用程式不再僅有一個邊界，應用程式被拆分開來。程式的複雜度降低，因為不同的的服務之間都有定義良好的互動。例如，允許為每一個服務指派一個團隊，負責實現這個抽象的部分。
• UI層僅需要與客戶及事件微服務互動，移除了對賬單微服務的依賴。
• 賬單微服務不需要儲存資料，它不需要資料訪問層及資料庫。它直接與客戶與事件微服務互動。

這種架構有著諸多優勢：

• 更易於關注點分離。各區域之間的界限能夠幫助開發（你只需要關注你自己的微服務，而不是整個應用程式）並能夠幫助理解程式的架構。
• 不像Monolith，微服務可以按照需求使用不同的技術棧。考慮使用一種新語言實現所有內容？僅僅讓一個微服務使用新的技術，評估獲得的好處，並決定是否繼續下去。
• 整個應用程式的部署變得更為幾種。微服務給予你釋出不同服務的靈活性。

在上面的例子中，有沒有注意到API與微服務其他部分放在一起？我們現在就解釋，終於可以講講微服務與API的差別了。

微服務與API的區別

微服務與API的主要差別如下：

• 一個API就是一個契約，為使用者提供指導使用對應的服務。
• 一個微服務是一種架構設計，將應用程式分成小的，自包含的服務。

根據定義，這意味著，API通常是微服務的一部分，允許微服務進行自我互動。換句話來說，API是作為微服務內部互動的契約，顯示與微服務互動的可用選項。

然而，如果我們看了上面的微服務圖，我們會發現每個微服務基於它的需求都有輕微的不同，以下是微服務可能有的不同功能的示例：

• 對一個特定的實體型別提供CRUD操作，例如客戶，事件等等。這個服務負責將資料持久化到資料庫。
• 提供一種方法來接收引數並基於計算返回結果。賬單微服務可以獲取使用者和事件資訊並返回所需的賬單資訊，不需要儲存資料。

通過上面的例子，我們可能已經發現微服務不僅僅是API。一個完整的應用程式可以包含一系列微服務，每個微服務都用自己的API彼此通訊。而且，每個微服務都可以抽象出自身的功能，畫出所負責的邏輯邊界並分離關注點以獲取更易維護的程式碼庫。

總結

希望現在你能更好地理解API與微服務。程式碼的可維護性與質量都是一個成功的IT策略的至關重要的部分。微服務令你可以兩者兼顧。他們使得你的團隊更加敏捷，幫助你滿足客戶需求，並開發出更高質量，更易於維護的程式碼。

你還在開發monolith程式碼嗎？考慮一下將那些程式碼分離成微服務吧。一旦你這麼做了，你應該就能看出使用微服務的好處。事實上，你甚至可能會轉換整個專案。