轉眼間工作已經有了一年半,工作之後所做的事情與預想中的還是有較大的差距的。回想一年多以來,大多數的時間都在處理業務邏輯或是重構已有的**,在前人的基礎上修修改改,真正的技術進步並不是很大。
做程式設計師這一行,還是要經常反省,時常學習的。在工作時間之外盡可能去了解一些工作接觸不到的知識面。在工作的第一年,讀了一些c++程式設計師的基礎書籍,今年準備讀一些更高層次的東西,比如框架,設計等,擴充套件一下視野。
本篇博文記錄一些筆者在閱讀《分布式服務框架原理與實踐》過程中一些比較經典的圖示或語句。
1.應用架構的演進
2.通訊框架
1、關鍵技術點
2、可靠性設計
3.序列化
序列化就是將物件序列化為位元組流用於不同程序之間的通訊。常見的序列化技術有谷歌的protobuf和facebook的thift,谷歌的效能更優。分布式框架應該支援擴充套件性,可擴充套件多種序列化方式。
4.協議棧
可靠性設計
協議的相容性和可擴充套件性
5.服務路由
1.透明化路由
2.路由規則
總的來說路由規則配置要足夠靈活,支援多種配置方式,實時生效,部分生效等。
6.集群容錯
集群容錯的場景
容錯策略
7.其他
基於註冊中心的訂閱發布
分布式事務設計
兩階段提交採用的是悲觀鎖策略,需要等待最慢的參與者,一旦協調者故障則整個事務就會阻塞。在分布式框架中,事務是一件很麻煩的事情。應盡量在業務層避免使用分布式事務。在大多數的業務場景中,我們可以使用最終一致性替代傳統的強一致性。
分布式事務原理與實踐
事務的核心是鎖和併發 事務這個東西優勢是方便理解 劣勢就是效能低 計算機就想乙個打字機,同時只能打入乙個字 要麼讀,要麼寫,要麼算 iops很低,但吞吐量高,大量的操作合併成乙個批量處理,效能最高。如何才能把大量操作合併成乙個進行處理呢,使用非同步 慢速裝置 磁碟,網路 使用非同步多執行緒的方式 樂...
分布式架構服務呼叫
和傳統的單體架構相比,分布式多了乙個遠端服務之間的通訊,不管是 soa 還是微服務,他們本 質上都是對於業務服務的提煉和復用。那麼遠端服務之間的呼叫才是實現分布式的關鍵因素 j a 原生 httpurlconnection是基於http協議的,支援get,post,put,delete等各種請求方 ...
Dubbo實現分布式架構原理
dubbo 框架是阿里巴巴開發的一款針對 soa服務式的分布式框架。隨著專案業務邏輯複雜度的提高,專案併發量的提高,將 dao層 service 層 web 層的所有 集中在乙個應用中已經不再適用,因為這樣專案維護起來很不便,代 碼冗雜在一起,專案之間的呼叫早已經含糊不清,對搭建集群節點也存在著制約...