微服務已經流行了好幾年了，現在已經是行業普遍的認識，技術方向的元件化也已經很成熟，dubbo，eurake，springboot，springcloud等等。大家也都張嘴就來服務註冊發現，api閘道器，服務熔斷，好像不了解微服務，不說上幾句就是技術不到位，就不能通過技術面試。
大家都在說，都集中在技術元件化的應用實現，但真正要落地微服務只靠技術元件堆積就能完美完成，那真是太好了！微服務真正落地，應該是始於業務規劃，業務拆分，業務重組，然後再利用開源or自研的技術元件將業務服務化、微粒化，從而達到微服務落地的目的。
要做微服務首先需要站在規劃角度知道為什麼要進行微服務，是否有必要微服務，它帶來的是利大於弊還是弊大於利。就拿我們微服務的例子來說，由於我們業務需求多來自內部，頻繁而零碎且開發周期要求極短，造成了大量的上線發布情況的發生，每次上線都需要中斷整個業務系統。且第一版系統沒有任何規劃完全是站在為了滿足業務方的需求而堆積起來的，所以很多功能越往後擴充套件越南，所以微服務對我們來說明顯的利大於弊。
要做微服務就一定要做業務拆分，站在總體現狀和未來規劃的基礎上，以業務架構的視角確定各業務邊界，還有微服務並不是一簇而就的，也是乙個演變過程。這兩年火遍大江南北的中颱建設細想想其實也是微服務的一種方式，只不過用了另一套概念來解釋和界定這個場景而已。
微服務架構，多「微」才合適？
以前的文章討論過 網際網路架構，究竟為啥要做服務化？隨著資料量 併發量 業務複雜度的增長，網際網路架構會出現以下問題 服務化 是乙個很好的解決上述痛點的方案。那麼問題來了，微服務架構多 微 才合適？行業內有這樣四類常見實踐。這是最粗獷的玩法，所有基礎資料，都通過乙個統一的服務來進行訪問。在業務不是特...
微服務 微服務簡介
什麼是微服務 顧名思義，就是粒度較小的服務，不再侷限於系統與系統之間的藉口呼叫，也不侷限於某種具體的服務形式。系統中凡是可被復用的功能模組都可以被 服務化 轉變為 服務 這些服務可以對外暴露，也可能僅限於再系統內部使用。由於服務數量更多，粒度更小，因此管控難度會更大，對效能的要求也更高。微服務的好處...
微服務 關於微服務的思考
通過kafka進行日誌收集，並結合elk進行日誌聚合 並通過日誌展示平台進行管理 引入elasticsearch 將所有微服務的資料庫需要查詢的資料同步到es中，增刪改仍然保持原有的mybatis運算元據庫 目前微服務之間的呼叫 bff呼叫基礎服務 使用的是rest請求方式，本質上還是http協議，...