小結前面我們了解了微服務化的拆分原則，以及從架構師角度如何權衡微服務化的利弊。這一章我們對微服務架構所要考慮的技術難點做一番**。
微服務架構可不是打嘴炮，它實打實地考驗乙個公司的綜合技術實力，這不僅關乎架構層面的技術選型，團隊成員對微服務體系的理解也決定著微服務化在執行層面的深度，而這套架構後面各個元件的線上部署維護也需要強大的運維能力。
所以說，在專案中應用微服務架構可謂是蜀道艱險，青天沒上成，可能先去了西天。
架構師是乙個很神奇的職業，為什麼這麼說呢，因為我工作中遇到的架構師，不誇張的說，80%都是ppt架構師，除了會寫ppt以外沒多大本事。脫離一線過久，**是寫不來了這輩子不會再碰**的，技術棧跟不上時代發展，架構脫離實際業務，沒有落地能力。
微服務架構的落地是要親身躬行，靠實踐經驗的積累才能做好的。接下來我們看一看在微服務改造的過程中，需要我們去攻克的技術難點。
微服務架構廣泛應用在超高併發系統中，中後台服務集群的規模著實不小。就拿淘系的下單介面來說，乙個下單指令要呼叫近二十個後台微服務協同完成任務（可能現在更多了），而在雙11這類業務場景下，核心鏈路的乙個微服務背後的虛機數量都有近萬台。
因此，服務與服務之間的呼叫，就成了微服務架構需要解決的第乙個問題。與此同時，大規模集群中虛機的上線下線是每天的日常任務，集群的擴容縮容也很常見，我們的微服務架構需要探知到集群中各個服務節點的狀態變化，這樣就知道哪些節點是可以正常提供服務的。我們管這個領域叫做服務治理
與服務治理搭檔的還有負載均衡，面對茫茫多的伺服器，如何將海量使用者請求分發到不同的機器。考慮到有的機器效能比較弱，或者機房頻寬不大，網路響應慢，如何根據實際情況動態地分發服務請求？這個領域就是負載均衡需要解決的事情。
地盤大了難免雜事不斷，集群中難免有那麼幾台機器跑著跑著就慷慨就義了。那麼對於其它的服務呼叫者來說，如果不巧正好呼叫到了這些掛掉的機器，那自然會獲得到失敗的response。面對這種情況，後台服務可有另一條路走？
在高併發場景下，有的服務會承擔較大的訪問請求，這有可能導致響應時間過慢，甚至會響應超時。那呼叫方在超時後經常會發起重試，這樣會進一步增加下游應用的訪問壓力，進而導致乙個惡性迴圈。那麼面對這種情況，我們有解決方案嗎？
以上就是微服務領域中降級和熔斷技術需要解決的問題，我們管這些叫做服務容錯。
大家平時在專案中都怎麼管理配置項呢？使用配置檔案？如果我有乙個業務場景，需要隨時調整配置，這種配置檔案的管理方式可能就玩不轉了，我們總不能每次改配置的時候都要重啟機器吧。
那麼把配置項存到資料庫裡？可以倒是可以，但是訪問量增加的時候也會將壓力傳導到資料庫，資料庫往往是比較弱不禁風的一環，很可能被壓垮。那麼放到快取裡？這一定程度上解決了效能問題，不過在某些業務場景下還是不好用，比如我希望給不同伺服器配置不同屬性值，指定name屬性在某100臺機器中的值是張三，在剩餘機器中的值是李四。
以上問題在微服務領域也不是什麼大問題，服務配置管理就是專門解決這類問題的利器。
我們的系統對外提供的網路訪問入口只有乙個，這通常就是乙個網域名稱**。但是這套系統後面的伺服器可有千千萬，那麼在微服務架構下，是如何將使用者請求**到每個不同的伺服器上的呢？這就是服務閘道器需要解決的事情。
學習過nginx的同鞋應該了解了閘道器的含義，不過在微服務領域裡，閘道器層會更加智慧型一些，它會感知伺服器上下線的變化。欲知微服務閘道器如何與服務治理搭配使用，且聽下回分解。
前面提到乙個淘系下單場景會呼叫一連串的微服務，我們yy這麼乙個線上故障，有個使用者買了兩隻大豬蹄子，結果東西送到家變成了兩隻雞爪子。店小二說沒發錯貨啊不信自己看訂單，開啟一看還真是，下單的時候選的豬蹄子，下單以後就成了雞爪子。
上面這個問題出在整個下單鏈路哪個環節呢？是訂單中心搞錯了商品id，還是購物車頁面傳了錯誤id給訂單系統，或者說搜尋頁面一鍵下單功能沒取到正確的id？迷霧迷霧在迷霧，怎麼撥開迷霧見真相？
呼叫鏈追蹤，從前到後整個呼叫鏈路全景資料展現，用事實說話，從此甩鍋更加精準！
訊息驅動是老朋友了，相信大家在專案中也經常使用訊息中介軟體。我們試想這樣乙個場景，雙11當天24點0分0秒一過，數萬萬的敗家親們一擁而上，下單介面呼叫量飆公升，就快到了崩潰邊緣。那我們後台的訂單服務如何才能頂住這一波波攻勢？親，訊息驅動元件加上限流元件來做削峰填谷了解一下？
不僅如此，微服務各個系統之間的解耦也可以用訊息元件來實現。其實訊息驅動在微服務裡的實現也就是多做了幾層抽象，呼叫起來更加方便，箇中滋味還請同學們親身體驗。
再厲害的系統也有效能瓶頸，強如阿里打造的雙十一也抵不住全國剁手族齊上陣，限流是最經濟高效，在源頭處消減系統壓力的手段。微服務的後台服務節點數量龐大，單機版限流遠不能解決問題，我們需要在伺服器集群這個範圍內引入分布式限流手段。
這一章跟大家介紹了微服務架構中的技術難點，在後面的章節裡，我們將使用spring cloud的十八般兵器，挨個解鎖上面的問題。
微服務架構核心（三） 微服務技術架構體系
微服務架構的名字裡雖然有個 微 但它涉及的整體架構體系可一點也不 微 微服務架構除了業務 的開發以外，還需要很多的支撐服務。每個公司都有自己的微服務架構體系，雖然在細節上有很多不同，但是整體的思路是類似的，下圖展示了乙個比較成熟的微服務架構體系。這個體系按照請求接入，由外到內的順序，將整體架構分為接...
微服務架構技術棧
一是 martin fowler 在其部落格上發表了 microservices 一文，正式提出微服務架構風格 二是 netflix 微服務架構經過多年大規模生產驗證，最終抽象落地形成一整套開源的微服務基礎元件，統稱 netflixoss，netflix 的成功經驗開始被業界認可並推崇 三是 piv...
微服務架構技術棧
微服務條目 落地技術 服務開發 spring springmvc springboot 服務配置與管理 netflix公司archaius 阿里diamond等 服務註冊和發現 eureka consul zookeeper 服務呼叫 rpc grpc rest 服務熔斷 hystrix envoy...