接觸微服務也有幾個月時間了，平時斷斷續續的會有一些關於微服務設計的思考，現在做個小結，與大家分享。
底部是用到的資料儲存設施，中間部分是今天的主角，微服務群，最上面是乙個統一入口，閘道器。
理想的系統應該是小核心，大業務。核心簡單、精幹、穩定；業務複雜、規則多、易變。業務呼叫核心，但是核心不會呼叫業務，需要的話可以走訊息，解耦。
如圖所示，微服務群中，深藍顏色的塊表示的就是核心微服務。icare-customer，使用者服務，基本上每乙個系統都需要；icare-account，賬戶服務，也是剛需；icare-order，訂單服務，交易的系統必要元件。仔細想想，這些服務一經開發完成，很少會有大的變化。
核心服務的乙個特點是，絕大多數業務都需要呼叫核心服務。是的，核心服務是基石。為了業務方呼叫方便，可以提供一些核心的介面出去，比如icare-***-share。注意，核心服務也能夠單兵直接對外提供服務。
業務服務不需要對其它微服務提供介面，如果有互動的需要，走訊息。icare-checkup，體檢服務；icare-car，用車服務；icare-ele，外賣服務 …
用node, nginx, zuul都可以做gateway。
gateway至少有以下好處:
1. 客戶端統一入口，簡化客戶端的服務呼叫。
2. 安全驗證的一道關卡，把非法訪問攔截掉，保護後面的微服務。
3. 承擔負載均衡的角色
微服務 關於微服務的思考
通過kafka進行日誌收集，並結合elk進行日誌聚合 並通過日誌展示平台進行管理 引入elasticsearch 將所有微服務的資料庫需要查詢的資料同步到es中，增刪改仍然保持原有的mybatis運算元據庫 目前微服務之間的呼叫 bff呼叫基礎服務 使用的是rest請求方式，本質上還是http協議，...
系統設計的幾點思考
前言又有好一陣子沒有更新文章了，今天聊聊系統設計的幾點思考。對於我們來說，始終會獨自設計，研發，迭代系統。為系統的演進，整個生命週期負責。而負責的系統到底處於什麼狀態？是否健康？是否出現問題？這些都是需要考慮的問題。開關對關鍵流程，進行開關設定。例如 交易開關，資金池開關。對於金融系統而言，特別是出...
關於微服務架構的思考
最近在專案中遇到了一些問題，乙個比較多的問題服務和服務直接呼叫混亂 a服務呼叫b b服務呼叫c c服務呼叫d 導致後期公升級會出現很多問題 如果有個流程圖也許會好些 但是沒有 因此我陷入了思考，如果進行重構的話那什麼樣的架構會是較好的 我想 設計模式的六大原則 在此也一樣適用 明確的分工,服務之間優...