(一)SpringCloud微服務
1 微服務特點: 實際就是業務垂直拆分的再次拆分.換一句話說,微服務比業務垂直拆分,划分的服務粒度更細.
優點: 每個子項目功能單一,結構清晰,代碼易維護.錯誤大量減少,出現BUG幾率也小,方便調試.加快調試時間.開發效率高,代碼量小,數據庫分開(優化:分庫分表)數據庫訪問壓力急劇降低.
缺點: 系統多了,系統之間調用變復雜,代碼跨網絡,TCP/IP二進制字節.Java轉換成二進制字節流(序列化,反序列化),耗費時間.網絡不穩定,影響程序的穩定性
2 微服務架構圖
圖解如下
1） Eureka注冊中心，服務提供者，服務消費者
2） Ribbon負載均衡，類似nginx
3） Feign REST封裝，接口，bug很多
4） Hystrix 斷路器
5） Zuul API網關
6） Sidecar異構語言支持，NodeJS
7） SpringCloudConfig配置中心，數據存在Git，版本控制
3 傳統項目與微服務項目對比圖
(二)注冊中心Eureka
釋義:注意它的特點，結構類似於MessageQueue消息隊列，服務（提供者、消費者）先都注冊到注冊中心。它的特點在於，不會每次都去注冊中心獲取，而是有本地緩存，加快訪問性能。內部含有心跳機制，當注冊中心信息改變，自動快速獲取新的信息到本地。心跳機制還保證分布式環境下，某個服務失敗后，自動列表從注冊中心移除。注冊中心中保證所有可用的鏈接。
(三)CAP定理
CAP原則又稱CAP定理，指的是在一個分布式系統中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可得兼。它是分布式系統中最核心最重要的理論。
分布式系統的CAP理論：理論首先把分布式系統中的三個特性進行了如下歸納：
一致性（C）：在分布式系統中的所有數據備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的數據副本）
可用性（A）：在集群中一部分節點故障后，集群整體是否還能響應客戶端的讀寫請求。（對數據更新具備高可用性）
分區容錯性（P）：以實際效果而言，分區相當於對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味着發生了分區的情況，必須就當前操作在C和A之間做出選擇。
CAP理論就是說在分布式系統中，最多只能實現上面的兩點。而由於當前的網絡硬件肯定會出現延遲丟包等問題，所以分區容忍性是我們必須需要實現的。所以我們只能在一致性和可用性之間進行權衡，要么選擇CP要么選擇AP，沒有分布式系統能同時保證這三點。
(四) ZooKeeper和Eureka對比
Eureka本身是Netflix開源的一款提供服務注冊和發現的產品，並且提供了相應的Java封裝。在它的實現中，節點之間相互平等，部分注冊中心的節點掛掉也不會對集群造成影響，即使集群只剩一個節點存活，也可以正常提供發現服務。哪怕是所有的服務注冊節點都掛了，Eureka Clients（客戶端）上也會緩存服務調用的信息。這就保證了我們微服務之間的互相調用足夠健壯。
Zookeeper主要為大型分布式計算提供開源的分布式配置服務、同步服務和命名注冊。曾經是Hadoop項目中的一個子項目，用來控制集群中的數據，目前已升級為獨立的頂級項目。很多場景下也用它作為Service發現服務解決方案。
對比
根據著名的CAP定理（C-數據一致性；A-服務可用性；P-服務對網絡分區故障的容錯性CAP這三個特性在任何分布式系統中不能同時滿足，最多同時滿足兩個CP或者AP）。
ZooKeeper
Zookeeper是基於CP來設計的，即任何時刻對Zookeeper的訪問請求能得到一致的數據結果，同時系統對網絡分割具備容錯性，但是它不能保證每次服務請求的可用性。從實際情況來分析，在使用Zookeeper獲取服務列表時，如果zookeeper正在選主，或者Zookeeper集群中半數以上機器不可用，那么將無法獲得數據。所以說，Zookeeper不能保證服務可用性。
誠然，在大多數分布式環境中，尤其是涉及到數據存儲的場景，數據一致性應該是首先被保證的，這也是zookeeper設計成CP的原因。但是對於服務發現場景來說，情況就不太一樣了：針對同一個服務，即使注冊中心的不同節點保存的服務提供者信息不盡相同，也並不會造成災難性的后果。因為對於服務消費者來說，能消費才是最重要的——拿到可能不正確的服務實例信息后嘗試消費一下，也好過因為無法獲取實例信息而不去消費。（嘗試一下可以快速失敗，之后可以更新配置並重試）所以，對於服務發現而言，可用性比數據一致性更加重要——AP勝過CP。
Eureka
而Spring Cloud Netflix在設計Eureka時遵守的就是AP原則。Eureka Server也可以運行多個實例來構建集群，解決單點問題，但不同於ZooKeeper的選舉leader的過程，Eureka Server采用的是Peer to Peer對等通信。這是一種去中心化的架構，無master/slave區分，每一個Peer都是對等的。在這種架構中，節點通過彼此互相注冊來提高可用性，每個節點需要添加一個或多個有效的serviceUrl指向其他節點。每個節點都可被視為其他節點的副本。
如果某台Eureka Server宕機，Eureka Client的請求會自動切換到新的Eureka Server節點，當宕機的服務器重新恢復后，Eureka會再次將其納入到服務器集群管理之中。當節點開始接受客戶端請求時，所有的操作都會進行replicateToPeer（節點間復制）操作，將請求復制到其他Eureka Server當前所知的所有節點中。
一個新的Eureka Server節點啟動后，會首先嘗試從鄰近節點獲取所有實例注冊表信息，完成初始化。Eureka Server通過getEurekaServiceUrls()方法獲取所有的節點，並且會通過心跳續約的方式定期更新。默認配置下，如果Eureka Server在一定時間內沒有接收到某個服務實例的心跳，Eureka Server將會注銷該實例（默認為90秒，通過eureka.instance.lease-expiration-duration-in-seconds配置）。當Eureka Server節點在短時間內丟失過多的心跳時（比如發生了網絡分區故障），那么這個節點就會進入自我保護模式。
總結
ZooKeeper基於CP，不保證高可用，如果zookeeper正在選主，或者Zookeeper集群中半數以上機器不可用，那么將無法獲得數據。Eureka基於AP，能保證高可用，即使所有機器都掛了，也能拿到本地緩存的數據。作為注冊中心，其實配置是不經常變動的，只有發版（發布新的版本）和機器出故障時會變。對於不經常變動的配置來說，CP是不合適的，而AP在遇到問題時可以用犧牲一致性來保證可用性，既返回舊數據，緩存數據。
所以理論上Eureka是更適合作注冊中心。而現實環境中大部分項目可能會使用ZooKeeper，那是因為集群不夠大，並且基本不會遇到用做注冊中心的機器一半以上都掛了的情況。所以實際上也沒什么大問題。
(四)分布式對關系型數據庫的沖擊
對於web網站來說，關系數據庫的很多主要特性卻往往無用武之地
數據庫事務一致性需求
很多web實時系統並不要求嚴格的數據庫事務，對讀一致性的要求很低，有些場合對寫一致性要求並不高。允許實現最終一致性。
數據庫的寫實時性和讀實時性需求
對關系數據庫來說，插入一條數據之后立刻查詢，是肯定可以讀出來這條數據的，但是對於很多web應用來說，並不要求這么高的實時性，比方說發一條消息之后，過幾秒乃至十幾秒之后，我的訂閱者才看到這條動態是完全可以接受的。如：MQ消息隊列機制，意義，可以解決瞬時的高並發，消峰填谷作用。
對復雜的SQL查詢，特別是多表關聯查詢的需求
任何大數據量的web系統，都非常忌諱多個大表的關聯查詢，以及復雜的數據分析類型的報表查詢，特別是SNS類型的網站，從需求以及產品設計角度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。
SNS：全稱Social Networking Services，專指社交網絡服務，包括了社交軟件和社交網站。例如：臉譜facebook、騰訊QQ、微信等。
飄向北方... ...