author/我在微服務圈子裡混

深度對比三種主流微服務配置中心

【編者的話】在撰寫這篇技術選型的文章之前,是比較猶豫的。因為,以其中一個開源專案開發者的身份,去寫一篇三個開源專案的對比,即便很剋制的去客觀的比較,也很難有信服力。這就像,既是參賽選手,又想做裁判,觀眾肯定是不

微服務呼叫鏈基本原理與使用

分散式系統之後,系統變的錯綜複雜,一般很難全盤理解整個系統,並且錯誤比較難定位,需要有呼叫鏈監控,快速的幫我們定位監控問題,瞭解微服務體系。 如果沒有應用監控: 線上釋出了服務,怎麼知道一切正常

微服務測試之介面測試和契約測試

日常開發過程中,專案的介面通常由服務提供方約定和提供,微服務模式下介面被多個消費者呼叫更是常態,那麼提供方介面的變更如何快速、高效、無遺漏的通知給消費者呢?另外,當一個service同時被多個使用者呼叫,如何保

微服務架構下,解決資料一致性問題的實踐

隨著業務的快速發展,應用單體架構暴露出程式碼可維護性差、容錯率低、測試難度大和敏捷交付能力差等諸多問題,微服務應運而生。微服務的誕生一方面解決了上述問題,但是另一方面卻引入新的問題,其中主要問題之一就是: 如

傳統企業就應該這樣進行微服務化

很多傳統企業看著網際網路公司都進行著微服務化,因此也想享受微服務化帶來的好處便對自己的系統進行改造,但微服務化 多“微”才是最優?有哪些拆分的原則? 架構原則 使用成熟的技術,不需要最

架構設計之「 微服務入門 」

微服務這幾年不可謂不火,很多技術團隊都開始在自己的專案上引入了微服務。一方面這些團隊確實很好的推動了微服務的應用和發展,另一方面也可以看到一些盲目追技術熱點的行為所帶來的危害,比如很多中小團隊對微服務的基礎知識

微服務學習歸納

寫在最前 照例嘮幾句,從《程式碼整潔之道》就認識了Martin,也拜讀他的部落格,從他提起微服務就一直挺有興趣,沒能抽出時間來實戰寫一個練手專案,今年開年後終於各種雜事都告一段落,開始慢慢啃書啃博文

1746045236.8215