服務治理
微服務架構需要知道集群各個服務節點的狀態變換，以及是否可以正常提供服務
負載均衡
與服務治理搭檔的還有負載均衡，面對茫茫多的伺服器，如何將海量使用者請求分發到不同的機器。考慮到有的機器效能比較弱，或者機房頻寬不大，網路響應慢，如何根據實際情況動態地分發服務請求？這個領域就是負載均衡需要解決的事情。
服務容錯
集群中難免有那麼幾台機器跑著跑著就慷慨就義了。那麼對於其它的服務呼叫者來說，如果不巧正好呼叫到了這些掛掉的機器，那自然會獲得到失敗的response。面對這種情況，後台服務可有另一條路走？
配置管理
放在資料庫？資料庫會掛
放在快取？不符合某些業務場景 比如想給不同的伺服器設定不懂的配置等?
服務閘道器
我們的系統對外提供的網路訪問入口只有乙個，這通常就是乙個網域名稱**。但是這套系統後面的伺服器可有千千萬，那麼在微服務架構下，是如何將使用者請求**到每個不同的伺服器上?(這和負載均衡有什麼關係) 的呢？這就是服務閘道器需要解決的事情。我們學習過nginx閘道器,在微服務領域裡，閘道器層會感知伺服器上下線的變化。
呼叫鏈路追蹤
前面提到乙個淘系下單場景會呼叫一連串的微服務，我們yy這麼乙個線上故障，有個使用者買了兩隻大豬蹄子，結果東西送到家變成了兩隻雞爪子。店小二說沒發錯貨啊不信自己看訂單，開啟一看還真是，下單的時候選的豬蹄子，下單以後就成了雞爪子。
上面這個問題出在整個下單鏈路哪個環節呢？是訂單中心搞錯了商品id，還是購物車頁面傳了錯誤id給訂單系統，或者說搜尋頁面一鍵下單功能沒取到正確的id？迷霧迷霧在迷霧，怎麼撥開迷霧見真相？
呼叫鏈追蹤，從前到後整個呼叫鏈路全景資料展現，用事實說話，從此甩鍋更加精準！
訊息驅動?
訊息驅動是老朋友了，相信大家在專案中也經常使用訊息中介軟體。我們試想這樣乙個場景，雙11當天24點0分0秒一過，數萬萬的敗家親們一擁而上，下單介面呼叫量飆公升，就快到了崩潰邊緣。那我們後台的訂單服務如何才能頂住這一波波攻勢？親，訊息驅動元件加上限流元件來做削峰填谷了解一下？
不僅如此，微服務各個系統之間的解耦也可以用訊息元件來實現。其實訊息驅動在微服務裡的實現也就是多做了幾層抽象，呼叫起來更加方便，箇中滋味還請同學們親身體驗。
限流為了防止流量過大
微服務基礎概念
服務級別可以從具體事故發生時服務對使用者體驗的影響 造成的損失等角度進行分級 服務的資料 在針對規範化資料模型存在的資料中心化問題中，微服務架構中資料管理的基本思路是資料去中心化，包括跨表查詢 跨庫查詢以及技術解耦等，其中主流採用的流程如下 分離 重複資料庫模式 遷移資料讀寫操作 抽取服務化介面 服...
微服務架構概念
微服務架構的系統是乙個分布式的系統，微服務是一種架構風格，乙個大型複雜軟體應用由乙個或多個微服務組，每個微服務執行在自己的程序中，並使用輕量級的機制通訊。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注於完成一件任務，每個微服務代表著乙個小的業務能力。這些服務可以使用不同的...
微服務概念講解
微服務概念講解 微服務是按照業務功能做拆分 在更大的專案中可能會將 封裝在處理不同業務服務中，按功能將 拆分成幾個服務，每個服務都是可獨立執行的。在專案開發中，可能有一部分 會在多個模組中頻繁的被用到，這種復用性很高的模組常常會抽離出來作為公共服務使用，比如驗證模組，當它要擴充套件功能 新增簡訊驗證...