微服務設計 讀後總結

#　微服務設計

1. 微服務的好處
2. 架構
3. 建模服務
4. 集成
5. 分解

1. 微服務的好處

• 技術的異構性，不一樣的服務能夠用不一樣的語言實現，甚至同一個服務用不一樣的語言實現。
• 彈性，也是很是重要的優勢，哪一個服務須要的資源多，多部署幾個就行了，而不是把整個項目都部署好幾套。
• 拓展，單個服務間是獨立的，因此拓展是不該該影響以前的服務，易於拓展
• 簡化部署，由於服務小，同彈性的優勢相同
• 可組合性
• 相對大型項目，改代碼時簡單

架構

面向服務的架構(SOA),這是一種設計方法，它所設計的系統包含多個服務，經過相互配合最終提供一系列功能。 每一個服務獨立運行，經過網絡調用，而不是進程之間。
這種設計咱們會有上述的好處，但也會面臨各類問題！在網絡中，使用什麼通訊協議、服務的粒度的大小斷定、中間件的選擇。而後再等到動手去作時，會出現事務怎麼一致啊，數據庫怎麼拆啊，之前的聯查怎麼辦啊等等一系列的問題！

建模服務

建模服務是書中的第三章，大概講的是建模服務的原則，總結6個字
鬆耦合，高內聚 遵循這個6個字，讓作的微服務能達到：

• 修改一個服務模塊時不須要修改另外一個
• 修改某一類功能時只修改一處就能夠

在書中我認識了個新名詞：洋蔥架構 ——」由於它有不少層，而 且 當 縱 切 這 些 層 次 時， 我 只 想 哭。「 以我目前只有2年的工做經驗，我還沒遇見想哭的。。。但以此自警，不要寫出讓人哭的東西！

集成

服務拆分紅功了，但怎麼集成？

好的集成：

1. 避免破壞性修改
2. API的技術無關性！
3. 服務易於消費方使用
4. 隱藏內部細節：消費方若是須要了解更多服務方細節的話，那麼就表明着消費方與服務方會發生過多的耦合

對於上述的第二點，咱們使用的是dubbo，因此API就是接口，因此咱們的微服務並無徹底獨立！噹噹開源的dubbox能夠提供http協議的接口

還有個數據共享的問題

• 例如未拆分前的靜態變量如何在多個子服務間共享？每一個微服務都要copy個代碼的話修改會不會太麻煩？或者有個服務專門提供這個數據，如放到數據庫中
• 數據庫有無拆分的必要？頗有必要，微服務是獨立的服務，若是改動該微服務的數據庫須要重啓等事件發生時，那麼和它共用數據庫的服務可能就要宕了！

編排和協同

這是個客戶下單過程

• 編排：客戶服務爲中心，調用其餘服務
  
• 協同：須要額外服務作監測
  

協同下降耦合，須要額外的監測服務。相對編排，改動時工做量少！我的也喜歡協同模式，這讓我想起了java中的觀察者模式，很是方便的開發方法~

對於相對小點的項目，也許‘編排’開發起來更簡單快捷

REST 和 RPC的對比

REST基於http相對低延遲的服務不如RPC，尤爲是在服務端與服務端之間，但RPC要客戶端和服務端代碼共享，也由於代碼共享，序列化和反序列化相對簡單。

Don't Repeat Yourself.

重複的代碼致使你修改時可能會漏掉某個地方。因此強制性要求，是有道理的，可是，微服務共享代碼時就會致使耦合現象！
客戶端庫：針對上述問題，網上有不少SDK，例如百度的雲存儲等SDK，實際上，這些sdk可能來自社區，例如阿里的sdk不少都是經過osc懸賞開發的，他們統一API，但具體客戶端實現和升級交給客戶。

接口數據的原則——寬進嚴出

對讀取的數據要有容錯性讀取，即對進來的數據，只找本身須要的，不須要的儘可能不去管。
該原則能夠幫助咱們在服務方發生變化時，減小消費方修改。

分解

考慮完集成咱們就開始分解吧！
不要爲了拆分而去拆分，是爲了哪部分代碼抽取出去後收益最大！

拆分所獲得的好處：

1. 速度提高，例如某個模塊須要大量修改時，拆分後只修改一個子項目，那麼後期開發速度會很快！
2. 團隊結構，分工更加明顯
3. 安全性

各個模塊分離開，安全就能提升嗎？

4. 技術

目前在技術上最大的幫助解決了大型項依賴雜亂！

數據庫的分離

1. 打破外鍵關係，因服務拆分後數據庫分離後，外鍵關係也所以打破，致使有些數據查詢須要經過API實現，儘管性能會有所下降，但慢也能接受。
2. 共享的靜態數據
   1. 要確保一致性——導出copy 代碼
   2. 作成配置文件——從代碼中提取出來改到配置文件
   3. 最複雜——單獨提供服務
3. 共享的數據——提供API接口
4. 共享的表——拆分

分離服務的步驟：

先拆分數據庫，再拆服務：因事務的關係，當服務未拆分時，還能保持事務的一致性。當數據庫分離的結果滿意後再實施下一步

事務！！！

• 最終一致性：協同操做的服務，其中一個服務出錯，能夠重試，最後一致便可！
• 補償事務
• 分佈式事務

須要保持一致性的場景的服務，就儘可能在一塊兒，若是避免不了也要避免使用純技術手段去解決，而是顯式的建立一個概念去表達這個事務。在此之上去補償或最終一致事務