有十來天沒發文了，實在抱歉！最近忙着錄視頻，同時也做了個開源的后台管理系統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