微服務是一種軟體架構風格，該詞**於martin fowler 的一篇部落格。他在自己部落格中闡述了微服務六個特點
創業初期
**很快完成後，找了家雲服務部署上線，開始了創業之路。
規模擴大
這一階段存在著很多不合理的地方：
做出改變
在程式設計的世界裡，最重要的是抽象能力，通過整理業務邏輯，抽象初公共的業務能力，做成了幾個公共的服務。各個應用只需要從這些服務獲取所需的資料，從而刪掉了大量冗餘的**，就生了輕薄的控制層和前端，這一階段的架構如下：
這一階段依然存在著很多缺點：
後來，一鼓作氣，把資料庫拆分了，所有持久化層相互隔離，由各個服務負責，此外，為了提高實時性，加入了訊息佇列機制。
完全拆分後各個服務可以採用異構的技術。比如資料分析服務可以使用資料倉儲作為持久化層，以便於高效地做一些統計計算；商品服務和**服務訪問頻率比較大，因此加入了快取機制等。
api閘道器
隨著業務的發展，服務越來越多，前端使用者如何呼叫微服務就成了乙個難題，因為他需要知道所有提供資訊的微服務。這個時候api閘道器的作用就體現出來了，通過api聚合內部服務，提供統一對外的api介面給前端系統，遮蔽內部實現細節。除此之外，api閘道器還可以進行安全認證、流量限制、日誌監控、防止爬蟲等等。
服務註冊與發現
乙個服務經常需要呼叫另乙個服務，在單一架構應用中，service通過語言層面或者程式層面去呼叫，在傳統的分布式系統部署中，服務執行在乙個固定的已知的位址（host和ports），從而可以簡單的被別的service通過http/rest或者某種rpc機制來呼叫。
在微服務架構中，乙個服務都會部署多個例項，這樣一來能夠分擔壓力提高效能，二來即使乙個例項掛了其他例項還能響應。並且服務例項的數量和網路位址都是動態變化的，這對系統運維提出了巨大挑戰，因此，動態的服務註冊與發現就顯得尤為重要。
熔斷當乙個服務因為各種原因停止響應時，呼叫方通常會等待一段時間，然後超時或者收到錯誤返回。如果呼叫鏈路比較長，可能會導致請求堆積，整條鏈路占用大量資源一直在等待下游響應。所以當多次訪問乙個服務失敗時，應熔斷，標記該服務已停止工作，直接返回錯誤。直至該服務恢復正常後再重新建立連線。
服務降級
當下游服務停止工作後，如果該服務並非核心業務，則上游服務應該降級，以保證核心業務不中斷。比如網上超市下單介面有乙個推薦商品湊單的功能，當推薦模組掛了後，下單功能不能一起掛掉，只需要暫時關閉推薦功能即可
限流乙個服務掛掉後，上游服務或者使用者一般會習慣性地重試訪問。這導致一旦服務恢復正常，很可能因為瞬間網路流量過大又立刻掛掉，在棺材裡重複著仰臥起坐。因此服務需要能夠自我保護——限流。限流策略有很多，最簡單的比如當單位時間內請求數過多時，丟棄多餘的請求。另外，也可以考慮分割槽限流。僅拒絕來自產生大量請求的服務的請求。例如商品服務和訂單服務都需要訪問**服務，商品服務由於**問題發起了大量請求，**服務則只限制來自商品服務的請求，來自訂單服務的請求則正常響應。
微服務實踐歷程
微服務概念的出現已經有很多年了，有多少公司在真正使用微服務，今天就把我這幾年對微服務的一點感受和大家分享下 首先，在系統建立之初，有乙個問題，到底要不要按照微服務的架構來開始專案？這個時候如果我們是接觸的乙個比較熟悉的行業 熟悉的業務，或者說業務架構師對這一行比較了解，那麼可以考慮進行微服務的設計，...
Abp vNext微服務實踐 服務通訊
服務通訊是微服務架構中必不可少的功能，服務通訊的效率決定了微服務架構的優略。常用的微服務通訊策略有兩種，分別是rpc http，其中rpc以grpc框架為代表使用者最多。abp vnext微服務架構中當然也有服務通訊策略，採用的是http方式進行服務通訊。雖然grpc高效安全，但是相關的.net框架...
微服務實踐 服務運維
監控的基本目標是掌控在生成環境中的服務執行狀況，在系統發生故障後及時報警，並能夠通過監控資訊快速定位問題。監控的另乙個目標是故障預警，在故障發生之前根據設定的規則提前感知並通知維護人員，或者自動做出運維決策。監控所涉及的指標 微服務的監控策略 對於微服務架構的系統，其監控通常由四大模組組成 資料收集...