1. 首頁 > 生活百科 > >

java分布式系統操作 java 分布式有哪些技術

生活百科服務


應用架構演進 這里的架構演進應該是從服務化的角度來說，應該說隨著業務發展，應用規模擴大，系統的一些公共服務就會抽取出來，獨立開發，部署，維護，用來解決并發，擴展，維護的問題 。
傳統垂直架構
有的地方也叫單體應用，以mvc模式開發：

    所有應用代碼統一打包，代碼所有接口本地api調用，很少存在遠程服務調用;單機或主備，應用做集群部署；DB主從等 。
這種并沒有什么不好，發展初期大多是這樣，體量沒那么大，也不需要考慮高并發大流量可擴展性什么的，簡單粗暴，解決業務需求就好，活下去才能活的更好 。
但是必須明白這種簡單架構存在的一些問題：
1. 業務不斷發展，功能逐漸增多，應用的開發維護成本變高，部署效率降低，隨便改個代碼，編譯一次十幾分鐘就浪費了 。悲劇，我們有個系統才開發3年，就碰到這種情況，一次打包編譯部署，13分鐘結束 。
2. 不同的人負責不同的部分，一些通用代碼、公共代碼就各寫各的，不能復用，如果只是util還好，但是一些外部服務的都有重復，那就happy了（不過這種情況的出現，不一定是架構問題，更多可能是管理）；
3. 不斷地上新需求，不斷地改代碼，有時測試不到位，指定哪里埋了bug，上生產后系統就down了，牽一發而動全身；
4. 可維護性，可靠性，擴展性變差 。
既然有這些問題，就要解決啊，業務就會提要求，你要解決啊，要不然影響我業務發展，影響我ipo上市啊，苦逼的碼農開始干活了 。
不提應用的拆分主從那些手段，但從拆分后應用交互看，原來的本地api交互變成的遠程api的調用，這里就出現了rpc，當然也有走esb，webservice 。其實拆分后挺麻煩的，光一個分布式事務就能折騰死人 。
RPC架構
Remote Procedure Call，遠程方法調用，屏蔽底層實現細節，像調用本地方法一樣調用遠程服務 。
上個作者的圖：
這個圖對于大多數rpc框架通用，實現的幾個技術點：
1. 服務提供者發布服務：服務接口定義，數據結構，服務提供者信息等；
2. 客戶端遠程調用：通常是使用jdk的代碼代理攔截；
3. 底層通信：現在應該更多是使用netty吧，當然也有走支持http的；
4. 序列化：關注序列化反序列性能，xml，json，hessiaon，pb，protostuff，kryo等；
作者給了個socket實現簡單demo，來實現遠程調用，說明上面幾個技術點 。
常用的rpc框架
1. Thrift；
2. Hadoop的Avro-RPC;
3. Hessian；
4. gRPC;
單論rpc的話，沒太多可說的，可是如果加上服務治理，那復雜度就幾何倍數增長了 。服務治理里面東西太多了，動態注冊，動態發現，服務管控，調用鏈分析等等問題這些問題，單憑rpc框架解決不了，所以現在常用的說的服務化框架，通常指的是rpc 服務治理2個點 。

猜你喜歡