什麼是微服務，它要幹啥

微服務， 強調一個“微”字，體現的是細粒度的高內聚、低耦合
它很小，專注於做好一件事

把因相同原因而變化的東西聚合在一起，把因不同原因而變化的東西分離開來
一個微服務應該在兩個內可以重寫
程式碼從你的筆記本到生產環境要多久

微服務需要隔離變化， 這個變化可能是由我們程式設計師比較關注的程式碼的業務邊界或者說限界上下文引起，比如商品管理和營銷活動設定；也可能是由於產品需求變化的速度不一致引起，比如商品基本資訊的管理和商品時效資訊（退改規則、費用說明等）調整的頻率就差距很大， 產品經理會經常調整時效資訊的文案和錄入規範； 或者是為了匹配部門的組織架構 等等。

隔離了變化後

1. 技術異構性得以支援，  每個服務可以選用最適合的技術棧去實現

2. 整體可用性的提升， 這個類似分散式系統帶來的部分不可用不影響整體主流程一樣的優勢

3. 部署的風險降低， 想象一下 修改一個小bug而不得不釋出整個龐大的專案

4. "微" 之後， 替換原來的實現方式（技術棧、重構）風險就會小很多，兩個星期內能重寫就太棒了
   ...

不過，既然是服務，就必須面對服務類架構需要解決的問題

1. 保證api的技術無關性，不使用平臺繫結的介面實現， 如提供的服務java能呼叫 .net能呼叫 python及其他也能呼叫

2. 協議的選擇， rpc 還是 rest， json 還是其他

3. 如何方便消費者使用 等
   其他可以參考下

微服務要快速上線， 需要持續整合，需要持續交付，需要測試來保證質量

那麼上線後是不是就沒事了？ 線上出了問題如何排查？ 你還得監控
微服務感覺散落一地的玻璃珠一樣， 需要監控小的服務，然後串起來看整體

或許你要跟蹤一長串呼叫鏈上每個節點的響應時長，還需要一個關聯標記來串起這個呼叫鏈看看呼叫節點之間的聯絡

程式碼從你的筆記本到生產環境要多久?  要清晰限界上下文，隔離變化原因，要可持續整合，持續交付，保證速度的同時也要保證質量...
其實，微服務不正是我們學習設計模式時和麵向物件程式設計時強調的各種原則的體現麼

作者：holysu
連結：
。