分散式系統的那些事兒 - SOA架構體系

我們們今天繼續說說分散式系統的那些事。

我們現在動不動就講分散式吧？那麼SOA是不是必須得聊一聊呢？

面向服務的架構，簡稱SOA，他是基於服務元件的，把原來那種一個大型應用程式的不同的功能拆分為一些介面，透過這些介面串聯起來。

這麼做的好處是：

1、重用性大大提高

2、明確了介面的服務定義規則

3、定義了自家公司的api標準

4、降低系統耦合性

5、無狀態HTTP

SOA不是技術也不是什麼標準，他是一個架構，每個公司對SOA的架構體系都不同，有簡單的也有複雜的，更有超越榮耀王者那邊的微服務存在。

曾經的SOA，我也參與過，那些介面設計十分複雜，用的是SOAP，資料傳輸透過xml來封裝的，雖然那個時候我還是個新手，但是我堅信這樣的不人性化的玩意遲早要被替代，如今restful風格的架構已經完全替代之。

現如今不論是SOA還是微服務。我們都會利用restful風格來做，甚至我們還會定義自己的一套標準規範，強制開發人員定義的所有api介面必須走這樣的規範，這麼做的好處是可以讓前後端分離，開發人員可以只專注自己的介面或者對接工作即可。

跟過時的SOAP相比，restful簡直就是簡介明瞭的實現方案。所有的服務都是松耦合，可以為第三方提供各式各樣的介面。傳播行為也十分輕量級。

restful的設計規範：

1、使用URL來同一表示我們的資源路徑，這個URL應該一目瞭然，讓人知道呼叫這個介面地址就能夠做什麼事

2、介面的同一定義：

對於增刪改查CRUD就有了十分明確的定義，request的請求方式有4種，

POST用於定義create操作；

GET用於定義查詢操作；

PUT用於定義修改操作；

DELETE用於定義刪除操作；

此外執行的那個業務方法名（action或者controller），必須定義為名字意義（對於這個我個人覺得沒必要，各自根據自己公司的業務定義即可，官方的規範很難以執行，而且命名會很糾結）

3、無狀態性：

普通的web應用我們都是用的session來管理使用者會話，但是restful的SOA中，我們必須得使用無狀態會話，sessionless，比如利用redis來實現，或者spring-session

4、返回客戶端的狀態：

我們得定義瀏覽器的狀態，就像404或者500那樣，出錯了得有一個狀態值，最常用的就是200狀態，然後就是501、502、503……這樣定義下去，而這個狀態需要封裝在你的一個json實體中讓對方獲取後進行解析，不論是ajax或者restful，都可以獲得這樣的json字串再轉換為想要的pojo

關於分散式，我們離不開的一個協調中介軟體就是zookeeper，我也在慕課網上做了套實戰課程，其中也包含了dubbo微服務入門，有興趣的朋友也可以關注一波: