SOA還是微服務？

在構建新的項目時應該總會考慮SOA或者微服務的方式。無論是新建還是重構。都請注意：考慮仍保持開放的選擇不採取這種方法。在讀完本文之後，關於是否建立多個小部件,你將會有一個更好的方法。

這篇文章是假定你有一些軟體架構和服務方面的經驗。我將談一些微服務或SOA，同時在你的項目中該如何做。

是微服務？還是SOA?都用？都不用？

有人說，微服務與SOA差別很大。也有人說，微服務與SOA有相同點，但是是SOA的下一代，輕量級和less-enterprisey什麼的。

完美構架不存在

你已經知道了沒有完美的軟體構架方法。Microsoavices可能不適合你的項目，甚至你的公司。什麼是microsoavice呢？首先，我想說明這個兩個簡單的關鍵點：

• l 細粒度的責任

• l 內置的容錯

他們是所有項目的基礎，無論你的項目是大還是小。

細粒度的責任

Microsoavices可以是單任務或單個域。下面是一個單任務microsoavice的一個例子。

所有的項目不僅包括業務邏輯和應用領域。總有一些會涉及普通工具。我曾經在一個需要將RTF文件轉換為HTML的項目。我們使用了一個庫，這是很容易的。另一方面，在更新庫時要求我們重新部署應用程序的所有實例。部署是自動化的，同時我們不需要發送新版本給客戶，但是對於只有三個人的團隊維護幾十個實例是要花點時間的。

將相同庫封裝到一個獨立的應用中然後去監聽所有的HTTP請求，把它變成一個microsoavice是必要的。總之，從那天起，更新該庫只是一個再部署一個單獨的組件的事（只要API保持穩定）。

除了單任務microsoavices，還有足夠多的用例覆蓋應用領域，而不只是單一任務的。拿一個購物車的例子來說。

• 添加商品到購物車

• 刪除商品

• 更改商品數量

沒有人為這些任務創建單獨的服務認真考慮過,這就是為什麼它是細粒度的。

內置容錯

進程內的方法調用,與外部組件間的調用替換。最大的區別在於，外部調用更容易失敗。它需要關注,但適當地考慮了它使整個系統更加穩定和容錯設計。

容錯真的是一個核心問題。早期把它弄對是microsoavices成功的關鍵。

問題

構建，部署和維護許多小的，獨立的組件組成的系統也帶來了許多的問題。你不僅要面對容錯的問題，還包括這些問題：

• 配置（我在哪裡實現這一服務？）

• 監控（提供哪些服務？）

• 部署（多少實例嗎？在哪些主機上運行它們）

• 測試（在服務呼叫失敗的情況下怎麼辦？）

• 等等問題

測試和部署應該考慮到持續集成和部署工具可用。中央microsoavice環境的配置可能是一些可以通過使用一些ESB-like工具解決。

似乎有一切的解決方案，你只是不太滿意。老實說，我認為我們沒有完全到那一步，當涉及到的工具。將來會帶來很多很好的工具，使構建，部署和維護microsoavices容易得多。

心態

從我自己的經驗來看，我可以說microsoavice不只是關乎技術問題，這真的是還有一些關於心態問題。

如果你擔心因為沒有單一故障的服務增加的失敗的概率，那麼你可能需要重新考慮一下了。如果你看到那些小的組件幫助你降低失敗的機率，你可能就能很快解決。

不要忘了你是一個開發人員。確保他們用mircosoavices的思想解決問題。我將在以後的工作中,microsoavices如何改變和提高開發人員的工作。

我的經驗

我做軟體開發近十年了。那段時間我的工作是不同類型的項目。我做了大約90％的網路用的東西Java和JavaScript，以及一些C＃.NET，Visual Basic中（預DOTNET），Perl，PHP，Python等等，我做了幾年的資深開發人員和架構師，也沒遇到過一個人處理從開發到部署和維修的團隊。

回想起來，我做了一些項目,一些人會從microsoavice方法中真正受益,一些人可能還沒有。我做過一個必須用SOA的項目，非常的不實用，這就是為什麼我想寫的務實的話題，並從實用角度看待項目。

了解更多Docker容器技術，關注微信公眾號「精靈雲」或「godocker」~