1、什么是微服務？
就目前而言，對於微服務業界並沒有統一的、標准的定義。
但目前而言，微服務架構是一種架構模式或者說是一種架構風格，他提倡將單一應用程序划分成一組小的服務，每個服務獨立運行在自己的進程中。每個服務之間相互協調、相互配合，為用戶提供最終價值。服務之間采用輕量級的通信機制（通常是基於HTTP的RESTful API）。獨立的部署，獨立的發布。極端情況可以是一個服務連一個數據庫，或者多個服務連接一個數據庫，非常靈活。
Cloud通信機制是RestFul api， 而Dubblo的通信機制是RPC（遠程過程調用）
2、SpringBoot和SpringCloud是什么關系？
SpringBoot關注的是微觀層面的，主要是一個個的微服務，可單獨使用，SpringCloud關注的是宏觀層面的，主要是微服務架構的一站式解決方案，必須依賴於SpringBoot才能使用。
SpringBoot專注於方便快速的開發單個個體微服務。
SpringCloud是關注全局的微服務協調整理治理框架，它將SpringBoot開發的一個個單體微服務整合並管理起來。為各個微服務之間提供，配置管理、服務發現、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分布式會話等等集成服務。
SpringBoot可以離開SpringCloud獨立使用開發項目，但SpringCloud離不開SpringBoot，屬於依賴的關系。
3、SpringCloud和Dubbo的區別？
最大區別：SpringCloud拋棄了Dubbo的RPC通信，采用的是基於Http的Rest API方式。
嚴格來說：這兩種方式各有優劣。雖然從一定程度上來說，后者犧牲了服務調用的性能，但也避免了上面提到的原生RPC帶來的問題。而且REST相比RPC更為靈活，服務提供方和調用方的依賴只依靠一紙契約（用json傳遞數據），不存在代碼級別的強依賴，這在強調快速演化的微服務環境下，顯得更加合適。
4、SpringCloud中使用Lombok工具
主要是目的是省略了javaBean中冗余代碼的編寫，如構造器、getset方法等，只需要使用工具會幫你在classes文件中生成對應的方法供調用。
5、SpringCloud封裝了Netflix公司開發的Eureka模塊來實現服務注冊與發現（請對比Zooker）.
Eureka采用了C-S的設計架構。Eureka Server作為服務注冊功能的服務器，它是服務注冊中心。
而系統中的其他微服務，使用Eureka的客戶端連接到Eureka Server並維持心跳連接。這樣系統的維護人員就可以通過Eureka Server來監控系統中各個微服務是否正常運行，SpringCloud的一些其他模塊（如Zuul），就可以通過Eureka Server來發現系統中的其他微服務，並執行相關的邏輯。
請注意和Dubbo架構對比
Eureka包含兩個組件：Eureka Server 和 Eureka Client
Eureka Server提供服務注冊服務。
各個節點啟動后，會在EurekaServer中進行注冊，這樣EurekaServer中的服務注冊表中將會存儲所有可用服務節點的信息，服務節點的信息可以在界面中直觀的看到。
EurekaClient是一個Java客戶端，用於簡化Eureka Server的交互，客戶端同時也具備一個內置的、使用輪詢負載算法的負載均衡器。在應用啟動后，將會向Eureka Server發送心跳（默認周期是30秒）。如果Eureka Server在多個心跳周期內沒有接到某個節點的心跳，EurekaServer將會從服務注冊表中把這個服務節點移除（默認90秒）
6、假如我們需要引入cloud的一個新技術組件，基本上有兩步：
1）新增一個相關的maven坐標 eureka
<!--eureka-server服務端 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka-server</artifactId>
</dependency>
2)在啟動類上面，標注啟動該組件技術的相關注解標簽
@SpringBootApplication
@EnableEurekaServer
public class EurekaServer7001_App {
public static void main(String[] args) {
SpringApplication.run(EurekaServer7001_App.class, args);
}
}
7、Eureka自我保護。
在自我保護模式中，Eureka Server會保護服務注冊表中的信息，不再注銷任何服務實例。直到收到的心跳數重新恢復到闕值以上時，該Eureka Server節點就會自動退出自我保護模式。它的設計哲學就是寧可保留錯誤的服務信息，也不可盲目注銷任何可能健康的服務實例。一句話就是：好死不如賴活着。
綜上，自我保護模式是一種應對網絡異常的安全保護措施。它的架構哲學是寧可同時保留所有的微服務（健康的微服務和不健康的微服務都會保留），也不盲目注銷任何健康的微服務。使用自我保護模式，可以讓Eureka集群更加的健壯、穩定。
在SpringCloud中，可以使用eureka.server.enable-self-preservation = false 禁用自我保護模式。
8、端口映射
修改C:\Windows\System32\drivers\etc\hosts文件。
|
127.0.0.1 eureka7001.com
127.0.0.1 eureka7002.com
127.0.0.1 eureka7003.com
127.0.0.1 myzuul.com
|
9、CAP
C: Consistency(強一致性)
A: Availability(可用性)
P: Partition tolerance(分區容錯性)
10、作為服務注冊中心，Eureka比Zookeeper好在哪里？
著名的CAP理論指出，一個分布式系統不可能同時滿足C（一致性），A（可用性）和P（分區容錯性）。由於分區容錯性P在分布式系統中必須要保證的，因此我們只能在AP之間進行選擇。
Zookeeper保證的是CP，Eureka則是AP。
Eureka可以很好的應對因網絡故障導致部分節點失去聯系的情況，而不會像Zookeeper那樣使整個注冊服務癱瘓。
11、Spring Cloud Ribbon是基於Netflix Ribbon實現的一套客戶端負載均衡的工具。
Ribbon負載均衡配置圖
Ribbon在工作時分成兩步
第一步先選擇EurekaServer，他優先選擇在同一個區域內負載較小的Server.
第二步再根據用戶指定的策略，在從server取到的服務注冊列表中選擇一個地址。
其中Ribbon提供了多種策略：比如輪詢、隨機和根據響應時間加權。
12、關於Ribbon的自定義算法，官方文檔明確給出了警告：這個自定義配置類不能放在@ComponentScan所掃描的當前包下以及子包下，否則我們自定義的這個配置類會被所有的Ribbon客戶端共享，也就是說我達不到特殊化定制的目的了。也就是這個配置類不能放在主啟動類所在包及其子包下。
13、Feign是一個聲明式WebService客戶端。使用Feign能讓編寫WebService客戶端更簡單，他的使用方法是定義一個接口，然后在上面添加注解，同時也支持JAX-RS標准的注解。Feign也支持可拔插式的編碼器和解碼器。Spring Cloud對Feign進行了封裝，使其支持了Spring MVC標准注解和HttpMessageConvertters.Feign可以與Eureka和Ribbon組合使用以支持負載均衡。
Feign集成了Ribbon
利用Ribbon維護了MicroServiceCloud-Dept的服務列表信息，並且通過輪詢實現了客戶端的負載均衡。而與Ribbon不同的是，通過feign只需要以聲明式的方法定義服務且綁定接口，優雅而簡單的實現了服務調用。
14、Hystrix是一個用於處理分布式系統的延遲和容錯的開源庫，在分布式系統中，許多依賴不可避免的會調用失敗，比如超時、異常等，Hystrix能保證在一個依賴出問題的情況下，不會導致整體服務失敗，避免級聯故障，以提高分布式系統的彈性。
“斷路器”本身是一種開關裝置，當某個服務單元發生故障之后，通過斷路器的故障監控（類似熔斷保險絲），向調用方返回一個符合預期的、可處理的備選響應（FallBack）,而不是長時間的等待或者拋出調用方無法處理的異常，這樣就保證了服務調用方的線程不會被長時不必要的占用，從而避免故障在分布式系統的蔓延，乃至雪崩。
15、分布式系統面臨的問題
復雜分布式系統體系結構中的應用程序有數十個依賴關系，每個依賴關系在某些時候將不可避免的失敗。
【服務熔斷】
一般是某個服務故障或者異常引起，類似“保險絲”，當某個異常條件被觸發，直接熔斷整個服務，而不是一直等到此服務超時，進而系統資源被大面積占用。
【服務降級】
整體資源快不夠用了，忍痛將某些服務先關掉，待度過難關，再開啟回來。它是客戶端完成的，跟服務端沒有關系。
16、Zuul包含了對請求的路由和過濾兩個最主要的功能：
其中路由功能負責將外部請求轉發到具體的微服務實例上，是實現外部訪問統一入口的基礎，而過濾器功能則負責對請求的處理過程進行干預，是實現請求校驗、服務聚合等功能的基礎，Zuul和Eureka進行整合，將Zuul自身注冊為Eureka服務治理下的應用，同時從Eureka中獲得其他微服務的信息，也即以后的訪問微服務都是通過Zuul跳轉后獲取。
注意：Zuul服務最終還是會注冊進Eureka
提供=代理+路由+過濾三大功能。
17、Config分布式配置中心是什么？
SpringCloud Config為微服務架構中的微服務提供集中化的外部配置支持，配置服務器為各個不同微服務應用的所有環境提供了一個中心化的外部配置。
SpringCloud Config分為服務端和客戶端兩部分。
服務端也稱為分布式配置中心，它是一個獨立的微服務應用，用來連接配置服務器並為客戶端提供獲取配置信息，加密/解密信息等訪問接口。
客戶端則是通過指定的配置中心來管理應用資源，以及與業務相關的配置內容，並在啟動的時候從配置中心獲取和加載配置信息，配置服務器默認采用Git來存儲配置信息，這樣就有助於對環境進行版本管理，並且可以通過git客戶端工具來方便的管理和訪問配置內容。