最近在學(xué)習(xí)和總結(jié)微服務(wù)的反模式和陷阱:
學(xué)習(xí)和歸納如下：
微服務(wù)的目標(biāo):
1.單體應(yīng)用的功能分隔成多個獨(dú)立的侥锦、功能單一的服務(wù)
2.單體應(yīng)用的數(shù)據(jù)分割成多個獨(dú)立的小數(shù)據(jù)庫
1驱入、數(shù)據(jù)驅(qū)動的遷移反模式
背景: 服務(wù)的拆分，導(dǎo)致數(shù)據(jù)的遷移键闺。如何避免頻繁的數(shù)據(jù)遷移（反模式）
太多的數(shù)據(jù)遷移：隨著服務(wù)的合并、拆分，數(shù)據(jù)頻繁的遷移余素。
策略: 應(yīng)該先功能分割優(yōu)先，數(shù)據(jù)遷移最后炊昆。
2桨吊、超時反模式
在分布式架構(gòu)中威根，管理服務(wù)的可用性和響應(yīng)。設(shè)置超時時間是一個選擇视乐。超時時間一般根據(jù)：
1.數(shù)據(jù)庫的超時時間
2.最長的負(fù)載計算時間
把這些值中的較大值*2洛搀，一般來說是超時時間的合理值。
但是為了判斷服務(wù)是否可用佑淀，而等上x秒留美，是超時反模式。
策略：使用斷路器伸刃。它會持續(xù)監(jiān)控服務(wù)的可用性谎砾，可以在毫秒對服務(wù)的可用性給出判斷∨趼可以通過心跳檢查或者用戶實(shí)時檢測的方式景图。
3、共享反模式
微服務(wù)是一直無共享的架構(gòu)隘道，或者稱為不共享模式症歇。總有些代碼會在不同的服務(wù)間共享谭梗。如果太復(fù)雜的依賴忘晤，將導(dǎo)致依賴惡夢。這將導(dǎo)致版本控制和發(fā)布的噩夢激捏。
常見的代碼共享技術(shù): 1.共享項(xiàng)目 2.共享庫 3.復(fù)制
4.到達(dá)報告反模式
一般都是業(yè)務(wù)服務(wù)和查詢服務(wù)數(shù)據(jù)庫分庫设塔，查詢（報表）服務(wù)的數(shù)據(jù)如何獲取到最新的業(yè)務(wù)數(shù)據(jù)庫呢? 主要有兩方面的問題:
1.如何及時獲得數(shù)據(jù)
2.如何保持?jǐn)?shù)據(jù)和服務(wù)之間的界限
常見的方式有：
1.Database pull模式：服務(wù)依賴于數(shù)據(jù)庫
2. HTTP pull 模式：慢
3. Batch pull 模式：查詢（報表）服務(wù)依賴于數(shù)據(jù)庫
4. Event-based push 模式：推薦。服務(wù)和數(shù)據(jù)之間隔離
5远舅、沙粒陷阱
服務(wù)粒度至關(guān)重要闰蛔，它會影響應(yīng)用的性能、健壯性图柏、可靠性序六、可測性、設(shè)置發(fā)布模型蚤吹。
太粗的話: 性能好例诀，但容易導(dǎo)致不容易測試和上線布署
太細(xì)的話: 容易上線部署、測速裁着，但通信成本高繁涂，影響性能
如何確定服務(wù)的粒度呢？
5.1二驰、分析服務(wù)的范圍和功能：同一服務(wù)的CRUD可以歸納為一個微服務(wù)扔罪。不相關(guān)的可以拆出來
5.2、分析數(shù)據(jù)庫事務(wù)：如果當(dāng)你需要在 ACID vs. BASE 事務(wù)中做艱難的決定的時候桶雀，可能你的服務(wù)劃分的就太細(xì)了矿酵。
5.3唬复、分析服務(wù)編排：如果一個服務(wù)需要與很多服務(wù)打交道才能完成功能，說明服務(wù)粒度太小坏瘩。
6盅抚、隨大流陷阱
為什么選擇微服務(wù):
優(yōu)點(diǎn)：
1.易部署
2.易測試
3.可擴(kuò)展
缺點(diǎn)：
1.性能
2.可靠性
3.運(yùn)維
7、REST陷阱
Rest是微服務(wù)的唯一選擇嗎?? 很多時候需要考慮一下AMQP消息：
1.優(yōu)勢: 時延短
2.異步處理：削峰填谷
3.廣播消息
4.事務(wù)消息
參考鏈接:
http://blog.csdn.net/u013970991/article/details/78079910
http://www.reibang.com/p/c76f7f234a31
https://blog.csdn.net/u013970991/article/details/78092048
