項目的API愈來愈多了,錯綜複雜,不少API管理混亂,不知道什麼應用調用了什麼API,每一個API的數據具體如何。。這個時候,天空出現了三個字「SOA」。。什麼是SOA,個人理解簡單來講就是把服務作成分佈式, 高可用,可統計的這麼一個玩意,俗稱面向服務架構體系。java
那怎麼實踐SOA呢?mysql
有現成的, 例如 dubbo, Consul, Thrift(姑且算是有點沾邊吧,實際上這玩意是多語言之間的RPC,能夠配合搞可用儲存作SOA的機型)。 如今國內比較熱的應該是 dubbo,是阿里作的, 以前用過一下,可是這玩意功能是強大, 不過客戶端語言貌似只支持 java, C++,如今我們項目的技術棧主流是PHP, golang因此暫時不考慮了,並且我的以爲有點臃腫,可能由於功能很強大吧。。。。git
Thrift 也是一個選擇, 能夠配合 Zookeeper來架構一個SOA的基形, 並且支持N種語言, 性能也不錯github
Consul國外挺多人貌似評價不錯, 不過我的沒玩過,不太瞭解。。golang
咱們此次選擇嘗試本身作一個輪子, 作一個SOA的基形,功能慢慢再加上去吧。sql
下面是咱們整個的模塊架構服務器
目前咱們的項目架構基本就是這樣, 不一樣的API散落在不一樣的服務器上, 由於原來有各個端,因此PHP一套, java一套, golang也一套,咱們先打算把API整理好,主要達到下面的目的。架構
1. 梳理各個API服務,根據訪問的流量考慮, 合理分配到不一樣的服務器負載均衡
2. 統計各API的流量狀況, 供應者是誰(就是哪臺服務器), 消費者是誰(就是哪一個應用調用了)運維
3. 接口透明化, 之後要作一個API都要問問身邊的同事, 接口地址多少啊? URL多少啊?之類的,如今直接把這塊封裝到 一個叫註冊中心的玩意裏面, 直接用 模塊/服務名稱 這樣的形式調用
4. 多語言一個玩, 能夠java寫服務,PHP調用, 或者換過來,或者選其餘語言等等
總體的技術架構
1. 由於是工做上用到,初期初版的註冊中心先用mysql,原本已經作好了集羣了(原本想選用ZK的,可是考慮到增長運維沒必要要的壓力,mysql徹底夠用了)
2. provider通訊這塊先用golang試下水作作, 看看性能如何吧。。這個性能上不去確定是不行的後期
3. 分佈式, 負載均衡, 權限控制這些功能慢慢再加上去, 初步考慮封裝好,放在消費者調用API以前這一層, 避免供應者容器二次鏈接通訊,參考了一下dubbo,好像他們也是這樣作的,固然人家都是java,持久運行,不用考慮這個
4. 須要快速寫個註冊中心的展現界面,有沒有大神參與一塊兒寫寫啊?公司人手不夠啊
由於這個也不屬於目前工做的業務範圍,只是先試水作出來,因此寫了一些代碼放到 github上,其實也是接觸SOA很少, 架構上應該有不少考慮不周,欠妥的地方,慢慢完善吧~~ :)
代碼地址: https://github.com/halokid/ttsoa, ttsoa, 代碼會不斷更新,有興趣的請提點反饋意見,謝謝~