架構的演進：
1.十年前：用戶->單一服務器->單一數據庫（支持十萬級用戶）
2.五年前：用戶->負載均衡器->多台服務器->緩存集群->主從數據庫（支持百萬級用戶）
3.近兩年：用戶->負載均衡器->網關集群->模塊1集群->模塊1數據庫集群
->模塊2集群->模塊2數據庫集群
->模塊3集群->模塊3數據庫集群
->......（支持千萬級用戶）
第三種方式稱為微服務，現在的大公司基本采用這種方式
微服務優勢與缺點
特性
-
每個微服務可獨立運行在自己的進程里；
-
一系列獨立運行的微服務共同構建起了整個系統；
-
每個服務為獨立的業務開發，一個微服務一般完成某個特定的功能，比如：訂單管理，用戶管理等；
-
微服務之間通過一些輕量級的通信機制進行通信，例如通過REST API或者RPC的方式進行調用。
特點
易於開發和維護
-
由於微服務單個模塊就相當於一個項目，開發這個模塊我們就只需關心這個模塊的邏輯即可，代碼量和邏輯復雜度都會降低，從而易於開發和維護。
啟動較快
-
這是相對單個微服務來講的，相比於啟動單體架構的整個項目，啟動某個模塊的服務速度明顯是要快很多的。
局部修改容易部署
-
在開發中發現了一個問題，如果是單體架構的話，我們就需要重新發布並啟動整個項目，非常耗時間，但是微服務則不同，哪個模塊出現了bug我們只需要解決那個模塊的bug就可以了，解決完bug之后，我們只需要重啟這個模塊的服務即可，部署相對簡單，不必重啟整個項目從而大大節約時間。
技術棧不受限
-
比如訂單微服務和電影微服務原來都是用java寫的，現在我們想把電影微服務改成nodeJs技術，這是完全可以的，而且由於所關注的只是電影的邏輯而已，因此技術更換的成本也就會少很多。
按需伸縮
-
我們上面說了單體架構在想擴展某個模塊的性能時不得不考慮到其它模塊的性能會不會受影響，對於我們微服務來講，完全不是問題，電影模塊通過什么方式來提升性能不必考慮其它模塊的情況。
缺點
運維要求較高
-
對於單體架構來講，我們只需要維護好這一個項目就可以了，但是對於微服務架構來講，由於項目是由多個微服務構成的，每個模塊出現問題都會造成整個項目運行出現異常，想要知道是哪個模塊造成的問題往往是不容易的，因為我們無法一步一步通過debug的方式來跟蹤，這就對運維人員提出了很高的要求。
分布式的復雜性
-
對於單體架構來講，我們可以不使用分布式，但是對於微服務架構來說，分布式幾乎是必會用的技術，由於分布式本身的復雜性，導致微服務架構也變得復雜起來。
接口調整成本高
-
比如，用戶微服務是要被訂單微服務和電影微服務所調用的，一旦用戶微服務的接口發生大的變動，那么所有依賴它的微服務都要做相應的調整，由於微服務可能非常多，那么調整接口所造成的成本將會明顯提高。
重復勞動
-
對於單體架構來講，如果某段業務被多個模塊所共同使用，我們便可以抽象成一個工具類，被所有模塊直接調用，但是微服務卻無法這樣做，因為這個微服務的工具類是不能被其它微服務所直接調用的，從而我們便不得不在每個微服務上都建這么一個工具類，從而導致代碼的重復
微服務的基礎名詞：
網關：路由轉發+過濾器
服務注冊發現：調用和被調用方的信息維護
配置中心：管理配置，動態更新
鏈路追蹤：分析調用鏈路耗時
熔斷：保護自己和被調用方
常見的微服務框架：
1.Dubbo系列：Zookeeper+Dubbo+SpringMVC/SpringBoot
應用：阿里，滴滴
通信方式：RPC
注冊中心：Zookeeper、Redis
配置中心：Diamond
2.SpringCloud系列：Spring系列+Netflix組件
通信方式：HTTP restful
注冊中心：Eruka、Consul
注冊中心：Config
熔斷器：Hystrix
網關：Zuul
分布式追蹤系統：Sleuth+Zipkin
區別和選擇：
1.Dubbo基於RPC，速度略高於Spring Cloud系列
2.Spring Cloud源於Spring，組件眾多
具體的區別可以參考大佬的博客：
https://blog.csdn.net/u010664947/article/details/80007767
比喻：
Dubbo
使用Dubbo構建的微服務架構就像組裝電腦，各環節我們的選擇自由度很高。
但是最終結果很有可能因為一條內存質量不行就點不亮了，總是讓人不怎么放心。
但是如果你是一名高手，那這些都不是問題。
Spring Cloud
而Spring Cloud就像品牌機。
在Spring Source的整合下，做了大量的兼容性測試，保證了機器擁有更高的穩定性。
但是如果要在使用非原裝組件外的東西，就需要對其基礎有足夠的了解。