最近在學(xué)習(xí)和總結(jié)微服務(wù)的反模式和陷阱:
學(xué)習(xí)和歸納如下：
微服務(wù)的目標(biāo):
1.單體應(yīng)用的功能分隔成多個獨立的、功能單一的服務(wù)
2.單體應(yīng)用的數(shù)據(jù)分割成多個獨立的小數(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.最長的負載計算時間
把這些值中的較大值*2，一般來說是超時時間的合理值。
但是為了判斷服務(wù)是否可用，而等上x秒，是超時反模式。
策略：使用斷路器。它會持續(xù)監(jiān)控服務(wù)的可用性，可以在毫秒對服務(wù)的可用性給出判斷?？梢酝ㄟ^心跳檢查或者用戶實時檢測的方式。
3、共享反模式
微服務(wù)是一直無共享的架構(gòu)，或者稱為不共享模式。總有些代碼會在不同的服務(wù)間共享。如果太復(fù)雜的依賴，將導(dǎo)致依賴惡夢。這將導(dǎo)致版本控制和發(fā)布的噩夢。
常見的代碼共享技術(shù): 1.共享項目 2.共享庫 3.復(fù)制
4.到達報告反模式
一般都是業(yè)務(wù)服務(wù)和查詢服務(wù)數(shù)據(jù)庫分庫，查詢（報表）服務(wù)的數(shù)據(jù)如何獲取到最新的業(yè)務(wù)數(shù)據(jù)庫呢? 主要有兩方面的問題:
1.如何及時獲得數(shù)據(jù)
2.如何保持數(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)致不容易測試和上線布署
太細的話: 容易上線部署、測速，但通信成本高，影響性能
如何確定服務(wù)的粒度呢？
5.1、分析服務(wù)的范圍和功能：同一服務(wù)的CRUD可以歸納為一個微服務(wù)。不相關(guān)的可以拆出來
5.2、分析數(shù)據(jù)庫事務(wù)：如果當(dāng)你需要在 ACID vs. BASE 事務(wù)中做艱難的決定的時候，可能你的服務(wù)劃分的就太細了。
5.3、分析服務(wù)編排：如果一個服務(wù)需要與很多服務(wù)打交道才能完成功能，說明服務(wù)粒度太小。
6、隨大流陷阱
為什么選擇微服務(wù):
優(yōu)點：
1.易部署
2.易測試
3.可擴展
缺點：
1.性能
2.可靠性
3.運維
7、REST陷阱
Rest是微服務(wù)的唯一選擇嗎?? 很多時候需要考慮一下AMQP消息：
1.優(yōu)勢: 時延短
2.異步處理：削峰填谷
3.廣播消息
4.事務(wù)消息
參考鏈接:
http://blog.csdn.net/u013970991/article/details/78079910
http://www.itdecent.cn/p/c76f7f234a31
https://blog.csdn.net/u013970991/article/details/78092048
