從幾個例子出發：
1.es的分片機制天生支援分布式，同時也帶來了分布式了弊端：排序和算分問題；
想要精確的算分和排序--->需要大量的計算和記憶體
如果資料量不大---->預設使用乙個分片---->不需要對排序和演算法另外處理/同時犧牲了分布式的特性（建議乙個業務場景的分片不超過20g。日誌索引的分片不超過50g），這也是為什麼7.x版本之後預設乙個分片
下面來看一下es的查詢過程：預設場景下的-----犧牲精準度保證效率
2.kafka與es面臨相同的問題：kafka的單個分區內可以保證順序性，分割槽之間是不能保證順序性的
如果是類似於日誌，不需要考慮訊息的順序性，那可以很好的發揮效能
如果需要保證順序性：
2.1）從業務上把需要有序的打到同乙個partition。因為大多數情況只需要業務上保證有序就可以，不用全域性有序（通過message key來定義，因為同乙個key的message可以保證只傳送到同乙個partition，比如說key是user id，table row id等等，所以同乙個user或者同乙個record的訊息永遠只會傳送到同乙個partition上，保證了同乙個user或record的順序）
那麼單個分片內kafka如何保證有序？
producer發訊息到佇列時，通過加鎖保證有序
現在假設兩個問題：
broker leader在給producer傳送ack時，因網路原因超時，那麼producer 將重試，造成訊息重複。
先後兩條訊息傳送。t1時刻msg1傳送失敗，msg2傳送成功，t2時刻msg1重試後傳送成功。造成亂序。
2.解決重試機制引起的訊息亂序
為實現producer的冪等性，kafka引入了producer id（即pid）和sequence number。對於每個pid，該producer傳送訊息的每個都對應乙個單調遞增的sequence number。同樣，broker端也會為每個維護乙個序號，並且每commit一條訊息時將其對應序號遞增。對於接收的每條訊息，如果其序號比broker維護的序號）大一，則broker會接受它，否則將其丟棄：
3.分布式的系統中路由演算法的弊端：增加/刪除節點時會有路由錯誤的問題（引發類似於快取雪崩的場景）
對應的解決方案：
3.1）如redis的一致性hash演算法
3.2）es同樣面臨類似的場景：每個index的主分片設定策略，動態分配會有大量的資料遷移，分配不合理又會影響效能
對此，es的解決方案是：index建立好之後不允重新設定分片，需要重新設定需要reindex
總結：根據不同的需求和場景，進行定製化的使用
微服務學習2 如何劃分微服務？
1 起點和終點 起點 既有架構的形態 終點 好的架構不是設計出來的，而是進化而來的 一直在演進ing 2 適合上微服務麼 業務形態不適合的 1 系統中包含很多很多強事務場景的 2 業務相對穩定，迭代周期長 3 訪問壓力不大，可用性要求不高 3，康威定律 任何組織在設計一套系統 廣義概念上的系統 時，...
微服務學習筆記 追蹤微服務呼叫
微服務系統追蹤微服務呼叫，跟蹤記錄一次使用者請求經過哪些呼叫，經過哪些服務處理，並且記錄每一次呼叫所設計的服務的詳細資訊。如果發生呼叫失敗，可以根據日誌快速定位出現問題的環節。一 作用 1.優化系統瓶頸 通過記錄呼叫經過的每一條鏈路上的耗時，快速定位系統中的瓶頸點。2.優化鏈路呼叫 通過服務追鍾可以...
微服務學習筆記 什麼是微服務
martin fowler 簡而言之，微服務架構風格這種開發方法，是以開發一組小型服務的方式來開發乙個獨立的應用系統的。其中每個小型服務都執行在自己的程序中，並經常採用http資源api這樣輕量的機制來相互通訊。這些服務圍繞業務功能進行構建，並能通過全自動的部署機制來進行獨立部署。這些微服務可以使用...