在寫下其他文字之前，必須先聲明下，這篇文章不是介紹討論關於分佈式技術的，而是討論分佈式架構在微服務架構中的價值和弊端。分佈式技術經過多年的發展，已經相對很成熟，相關文章很多，所以不是本文的重點。
在閱讀下文之前，我推薦先閱讀以下三篇文章，特別是最後一篇，有比較完整的闡述。
- http://2012.33degree.org/pdf/JamesLewisMicroServices.pdf
- https://archive.oredev.org/oredev2012/2012/sessions/micro-service-architecture.html
- https://martinfowler.com/articles/microservices.html
微服務天生是分佈式，這跟具體的實現措施沒有關係，而是根據他的定義來看，就應該是這樣的。之前我也談過，微服務的核心在於一個“微”字，這個方法帶來了很多好處，就像現在工業化的分工合作一樣，越來越細緻；但也帶來了之前沒有遇到的問題，就是進程多，也因此導致了管理上的難度。
Martin Fowler在闡述微服務的時候，強調了去中心化治理和去中心化數據管理，這和分佈式架構是不謀而合的。但我們也必須看到，分佈式架構即使發展這麼多年過去，還是沒有被業界廣泛採用，不是沒有原因的。
分佈式架構在整體的技術難度上來講，遠遠超過了其他架構，而是被頻繁的應用於某些基礎組件中，比如分佈式文件系統，GFS。更在技術難度較低的業務系統，並沒有太多的應用。Martin Fowler爲此也補充說，基礎設施自動化。微服務的核心在於一個“微”字，由此導致了一個“多”字，即服務多了。之後發展起來的調度、治理以及自動化，都是爲了解決這些問題。
講個真實遇到的小故事，有次聽人介紹他公司產品的時候，說他們很早前採用了微服務架構。我很好奇地問了句，你們有多少個進程？20多個！嗯，是我哪裏理解有問題嗎？
微服務必須是分佈式嗎？其實不見得。這需要仔細權衡業務現狀和成本問題。分佈式的技術難度必然導致了研發成本和時間居高不下，如果只有20多個服務進程的業務，去搞微服務架構也要硬套上分佈式技術，除了太有錢想不開外，更大的可能是對投資人不負責任。
微服務必須是HTTP API嗎？我很反對這個說法。雖然說，互聯網是最大的分佈式系統，HTTP協議功不可沒。但在微服務架構中普遍採用HTTP API，即使是RESTFUL也是很危險的想法。HTTP以同步調用模式爲主，即使後面異步模式有所發展，但支持並沒有那麼友好。微服務因爲調用鏈變長，所以服務失效的風險指數增大，學過概率統計的人可以自己計算下。在一個變長的調用鏈中，嵌入同步調用模式，後果可想而知。讓HTTP API作爲一種網關協議，在靠近最終用戶的地方，可以是被調用纔是最好的方式。
基於MQ是一種很好的微服務實踐方式。MQ以消息作爲數據交換協議，和HTTP+json等可以進行良好的轉換，而且也支持PRC模式。更重要的是，MQ是異步和長連接模式，在吞吐量、延遲以及異常捕獲方面都由於HTTP模式。因此，在系統內部以MQ爲主，在系統邊界處支持HTTP/RPC等其他方式，讓整個系統具備更好的兼容性。
在MQ早期發展中，主要以集羣方式出現的，比如SOA架構中ESB之類的。在持續發展中，分佈式總線也得到了發展，甚至在早前微服務出現之前，就已經出現了分佈式總線產品。以哪種MQ作爲基礎組件，還是要考慮產品和團隊的現狀來做決定的。
在微服務架構發展到現在，已經出現了很多開源項目，比如spring系列，降低了企業實踐微服務的技術難度，成本也沒有早前難以接受。但在後期維護的難度和成本依然不容小覷，特別是在生產環境中出現故障，那麼基礎設施的故障會導致難以承受的代價。
分佈式架構是微服務架構的優秀實踐，但是否要按照這個方式來實踐，要充分考慮自身的現狀，在成本和效果之間進行有效的權衡。