SpringCloud
什么是微服務？
要想學習微服務，首先需要知道什么是微服務？為什么會有微服務？相信看完架構的發展史讀者就會明白
架構發展史
單體應用架構
如圖所示：將所有的模塊，所有內容(頁面、Dao、Service、Controller)全部寫入一個項目中，放在一個Tomcat容器中啟動適用於小型項目
優點：開發速度快，可以利用代碼生成工具快速的開發一個項目
缺點：不易擴展，代碼耦合度高，且不容錯(當某部分出錯后整個服務就會停止運行)
垂直架構
既然原來單體架構中代碼耦合度高，不利於維護和運行，人們自然就想到將不同的內容分開。最簡單合理的方式就是將系統按照功能划分成不同的模塊，然后將各模塊獨立放入不同的Web容器中，這就形成了垂直架構
優點：代碼耦合度降低，且不同模塊之間可以獨立運行。一旦某個模塊壓力過大，可以針對性的搭集群
缺點：模塊之間有可能不是那么完全獨立，導致實體類或者其他層代碼不能復用，需要多出粘貼，不方便日后維護。如果直接通過HTTP調用又不是很合理。
分布式架構/分布式SOA架構
分布式架構顧名思義就是分散部署在不同的機器上的服務，一個服務可能負責幾個功能，是一種面向SOA架構的，服務之間也是通過rpc來交互或者是webservice來交互的架構。從開發的角度看就是Controller層(服務消費者)和Service層(服務提供者)分成不同的項目，部署在不同的服務器上，通過RPC(遠程方法調用)來實現交互。阿里巴巴著名的Dubbo框架就是作為分布式架構的框架。一般推薦使用Zookeeper作為服務的注冊中心，負責注冊和發現服務的提供者，並供服務的消費者消費
微服務
單體架構和微服務的比較圖示：
微服務的核心就是將傳統的一站式應用，根據業務拆分成一個個原子應用。徹底地去耦合，一個服務只做一件事情，從技術角度講就是一個服務就是一個進程，可以單獨啟動或銷毀，擁有獨立的數據庫。並且通過配置中心可以方便的切換數據庫等。
優點：
- 每個服務足夠內聚，足夠小，代碼容易理解，一個服務可能就是專一的只干一件事。開發簡單、開發效率提高
- 微服務能夠被小團隊單獨開發，這個小團隊可以是由2到5人的開發人員組成
- 微服務能使用不同的語言開發。易於和第三方集成，微服務允許容易且靈活的方式集成自動部署，通過持續集成工具，如Jenkins, Hudson, bamboo 。微服務允許你利用融合最新技術。
- 微服務易於被一個開發人員理解，修改和維護，這樣小團隊能夠更關注自己的工作成果。無需通過合作才能體現價值。
缺點：
- 開發人員要處理分布式系統的復雜性，會面臨分布式事務、分布式一致性等問題
- 多服務運維難度，隨着服務的增加，運維的壓力也在增大
- 服務間通信成本變高
微服務的技術棧
| 微服務條目 | 落地技術 | 備注 |
|---|---|---|
| 服務開發 | Springboot、Spring、SpringMVC | |
| 服務配置與管理 | Netflix公司的Archaius、阿里的Diamond等 | |
| 服務注冊與發現 | Eureka、Consul、Zookeeper等 | |
| 服務調用 | Rest、RPC、gRPC | |
| 服務熔斷器 | Hystrix、Envoy等 | |
| 負載均衡 | Ribbon、Nginx等 | |
| 服務接口調用(客戶端調用服務的簡化工具) | Feign等 | |
| 消息隊列 | Kafka、RabbitMQ、ActiveMQ等 | |
| 服務配置中心管理 | SpringCloudConfig、Chef等 | |
| 服務路由（API網關） | Zuul等 | |
| 服務監控 | Zabbix、Nagios、Metrics、Spectator等 | |
| 全鏈路追蹤 | Zipkin，Brave、Dapper等 | |
| 服務部署 | Docker、OpenStack、Kubernetes等 | |
| 數據流操作開發包 | SpringCloud Stream（封裝與Redis,Rabbit、Kafka等發送接收消息） | |
| 事件消息總線 | Spring Cloud Bus |
什么是Spring Cloud
Spring Cloud 是實現微服務思想落地開發的一整套技術的集合
Spring Cloud和Dubbo的區別圖解
Spring Cloud開發者文檔中文版：
https://springcloud.cc/spring-cloud-dalston.html
Spring Cloud中國社區
Spring Cloud中文網