架構的演進：
1.十年前：使用者->單一伺服器->單一資料庫（支援十萬級使用者）
2.五年前：使用者->負載均衡器->多台伺服器->快取集群->主從資料庫（支援百萬級使用者）
3.近兩年：使用者->負載均衡器->閘道器集群->模組1集群->模組1資料庫集群
->模組2集群->模組2資料庫集群
->模組3集群->模組3資料庫集群
->......（支援千萬級使用者）
第三種方式稱為微服務，現在的大公司基本採用這種方式
每個微服務可獨立執行在自己的程序裡；
一系列獨立執行的微服務共同構建起了整個系統；
每個服務為獨立的業務開發，乙個微服務一般完成某個特定的功能，比如：訂單管理，使用者管理等；
微服務之間通過一些輕量級的通訊機制進行通訊，例如通過rest api或者rpc的方式進行呼叫。
易於開發和維護
啟動較快
區域性修改容易部署
技術棧不受限
按需伸縮
運維要求較高
分布式的複雜性
介面調整成本高
重複勞動
微服務的基礎名詞：
閘道器：路由**+過濾器
服務註冊發現：呼叫和被呼叫方的資訊維護
配置中心：管理配置，動態更新
鏈路追蹤：分析呼叫鏈路耗時
熔斷：保護自己和被呼叫方
常見的微服務框架：
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，元件眾多
比喻：dubbo
使用dubbo構建的微服務架構就像組裝電腦，各環節我們的選擇自由度很高。
但是最終結果很有可能因為一條記憶體質量不行就點不亮了，總是讓人不怎麼放心。
但是如果你是一名高手，那這些都不是問題。
spring cloud
而spring cloud就像品牌機。
在spring source的整合下，做了大量的相容性測試，保證了機器擁有更高的穩定性。
但是如果要在使用非原裝元件外的東西，就需要對其基礎有足夠的了解。
學習SpringCloud（1）簡介
spring cloud是一系列框架的有序集合。它利用spring boot的開發便利性巧妙地簡化了分布式系統基礎設施的開發，如服務發現註冊 配置中心 訊息匯流排 負載均衡 斷路器 資料監控等，都可以用spring boot的開發風格做到一鍵啟動和部署。spring cloud並沒有重複製造輪子，它...
SpringCloud系列 1 初試微服務
微服務 之前在寫springboot的筆記時，就有提及到springcloud。springcloud提供了微服務的開箱即用。微服務近年來非常火，到處都在說微服務。筆者也對微服務相當感興趣，因為筆者在校期間 n年前 曾經和很多同學聊過，如果所有的應用並不是單體的，而是通過很多系統提供api這會變成怎...
SpringCloud 微服務與微服務對接心德
對方已經提供好乙個api文件，然後傳一堆傳輸，返回給我一些資訊。如下 我這邊建立實體類，返回值這些東西，如下 介面如下 feignclient還有以下標籤 name 指定feignclient的名稱，如果專案使用了ribbon，name屬性會作為微服務的名稱，用於服務發現 url url一般用於除錯...