分布式系統的那些事兒（六） - SOA架構體系

有十來天沒發文了，實在抱歉！最近忙著錄視頻，同時也做了個開源的后臺管理系統LeeCX，目前比較簡單，但是后續會把各類技術完善。具體可以點擊“原文鏈接”。

那么今天繼續說分布式系統的那些事。

我們現在動不動就講分布式吧？那么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

?