前言
認真研讀了極客時間的微服務文章（https://time.geekbang.org/special/microservice-architecture），整體介紹比較全面，特此記錄一下；
1. 服務注冊，服務提供方將自己調用地址注冊到服務注冊中心，讓服務調用方能夠方便地找到自己。(Zookeeper、Etcd, Eureka)
2. 服務發現，服務調用方從服務注冊中心找到自己需要調用的服務的地址。
3. 負載均衡，服務提供方一般以多實例的形式提供服務，負載均衡功能能夠讓服務調用方連接到合適的服務節點。并且，節點選擇的工作對服務調用方來說是透明的。
4. 服務網關，服務網關是服務調用的唯一入口，可以在這個組件是實現用戶鑒權、動態路由、灰度發布、A/B 測試、負載限流等功能。（開源方案：Spring Cloud Zuul）
5. 配置中心，將本地化的配置信息（properties, xml, yaml 等）注冊到配置中心，實現程序包在開發、測試、生產環境的無差別性，方便程序包的遷移。
6. API 管理，以方便的形式編寫及更新 API 文檔，并以方便的形式供調用者查看和測試。(文檔：swagger，調用鏈分析，api測試？)
7. 集成框架，微服務組件都以職責單一的程序包對外提供服務，集成框架以配置的形式將所有微服務組件（特別是管理端組件）集成到統一的界面框架下，讓用戶能夠在統一的界面中使用系統。
8. 分布式事務，對于重要的業務，需要通過分布式事務技術（TCC、高可用消息服務、最大努力通知）保證數據的一致性。(這個才是整個微服務架構的難點)
9. 調用鏈，記錄完成一個業務邏輯時調用到的微服務，并將這種串行或并行的調用關系展示出來。在系統出錯時，可以方便地找到出錯點。
10. 支撐平臺，系統微服務化后，系統變得更加碎片化，系統的部署、運維、監控等都比單體架構更加復雜，那么，就需要將大部分的工作自動化。現在，可以通過 Docker 等工具來中和這些微服務架構帶來的弊端。 例如持續集成、藍綠發布、健康檢查、性能健康等等。嚴重點，以我們兩年的實踐經驗，可以這么說，如果沒有合適的支撐平臺或工具，就不要使用微服務架構。
11、運維：包含自動構建、自動部署、日志中心、健康檢查、性能監控等功能。
12、微服務實踐：業內成熟方案：Netflix 的微服務方案和 Spring Cloud
思考：如何進行模塊化開發
書籍推薦：
參考文檔
