作者介紹：
楊波，微服務技術專家，曾主導了拍拍貸微服務架構體系建設。任職攜程技術研發總監期間，主導了攜程大規模SOP體系建設，也是極客時間「微服務架構實戰160講」課程講師。
一、OAuth2的四種模式該如何選擇？
OAuth2協議主要規範了四種授權模式，在實際應用中選型的時候，我們主要通過如下三個維度進行考慮：
第一方還是第三方應用？
所謂第一方應用就是你足夠信任的組織開發的應用，例如淘寶App是淘寶自己開發的，對它的授權方式是淘寶充分信任的，可以認爲是第一方應用。所謂的第三方應用就是你並不信任的組織開發的應用，例如某第三方公司基於淘寶開放API開發的App，淘寶並不信任這個應用，那麼它就是第三方應用。
誰擁有訪問令牌？
授予訪問令牌表示授予客戶應用一種權限，能夠去訪問受保護的資源。如果你授權機器去訪問資源，不需要用戶的參與，那麼就採用客戶端憑證模式(Client Credentials Grant)。如果需要用戶參與授權，那麼還要繼續看客戶類型。
哪種客戶應用類型？
- Web服務器端應用，客戶應用住在Web服務器上，使用授權碼模式(Authorization Code Grant)。
- 單頁SPA應用，整個Web應用都住在前端瀏覽器中，對於第一方應用，可以使用用戶名密碼模式(Resource Owner Credentials Grant)；對於第三方應用，使用簡化模式(Implicit Grant)。
- 原生Native應用，對於第一方的無線原生應用，可以使用用戶名密碼模式；第三方的原生應用應該使用授權碼模式，注意要使用原生瀏覽器，而不是使用嵌入式的瀏覽器。
二、如何理解Apollo配置中心的架構？
在2018年度最受歡迎開源軟件評選中，攜程開源配置中心Apollo名列Top20之內，這一方面說明Apollo解決了微服務應用配置複雜的一大痛點，同時也說明社區對微服務需要集中配置的普遍認同。Apollo配置中心架構相對複雜，但理解其架構對正確部署和使用Apollo非常重要，Apollo本身採用微服務架構，使用了服務發現和軟負載等分佈式技術，它的核心組件和服務發現機制如下：
- Client&ConfigService：Apollo客戶端Client通過ConfigService感知並獲取實時配置。兩者的發現機制是，ConfigService啓動時首先註冊到Eureka，Client再通過MetaServer(相當於Eureka Proxy)獲取ConfigService的地址列表，並通過客戶端軟負載的方式連接ConfigService。這個連接採用long pulling方式，支持ConfigService實時推送數據到Client，且Client會定期重連獲取配置，實現推拉結合效果。
- Portal&AdminService:Portal是給用戶使用的配置管理(添加、修改和發佈等)界面，AdminService是實際操作配置的接口服務。兩者的服務發現機制是，AdminService啓動時首先註冊到Eureka，Portal再通過MetaServer(Eureka Proxy)獲取AdminService的地址列表，並通過客戶端軟負載的方式調用AdminService。
- Eureka&MetaServer：Apollo採用Eureka做服務發現。在服務提供端，ConfigService和AdminService啓動時會自動註冊到Eureka。服務消費端比較複雜，首先，Apollo引入MetaServer以屏蔽Eureka服務發現接口的複雜性，簡化多語言客戶端接入，MetaServer相當於是Eureka Proxy；其次，MetaServer無狀態以集羣方式部署，需要前置Nginx做負載均衡；最後，Client和Portal通過Nginx->MetaServer->Eureka方式間接發現目標服務。
三、微服務網關Zuul承擔哪些核心職責？
網關在微服務基礎架構中承擔重要職責，這些職責一般是非業務性的，稱爲跨橫切面職責(cross-cutting concerns)，包括：
1. 單點入口：企業內部的系統雖然是由諸多微服務組成，但是對於外部的客戶端來說，這些內部細節可能會不斷變化，應該被隱藏，即網關爲外部客戶隱藏內部實現細節，提供單一抽象入口。另外，通過引入網關這層抽象，讓內外兩邊不強耦合，可以相互獨立變化。
2. 路由轉發：由於外部客戶端看到的是單點入口，而內部是複雜的微服務系統，當請求進入的時候，網關需要將請求按照某種規則(例如根據請求path)定位並轉發到內部具體的微服務，即網關要承擔路由轉發的職責。
3. 限流熔斷：面對外部的突發流量(比如雙十一促銷)，網關需要有限流和熔斷的能力，保護後臺服務不被突發流量沖垮。
4. 日誌監控：網關是外部流量到內部系統的集中入口點，非常適合收集訪問日誌，對流量進行集中監控。
5. 安全認證：同樣由於集中入口點的特性，網關非常適合承擔集中安全認證、防爬蟲防攻擊等職責。
Zuul是經過Netflix大規模微服務落地驗證，後被Pivotal進一步封裝推廣的一款生產級的微服務網關，通過Zuul特有的可插拔過濾器(pluggable filter)機制，可以很方便地實現上述職責。
四、如何使用CAT進行微服務調用鏈埋點？
對一個分佈式微服務系統進行埋點，爲了將端到端的調用鏈串起來，一些關鍵的地方需要埋點：
- 網關的入口和出口：網關是外部客戶接入內部系統的集中入口，適合採用CAT進行集中埋點，在請求進入的地方需要埋點，按照CAT的術語，這個地方產生的叫Root Transaction，表示整個調用鏈的啓動，在調用後臺服務的地方也需要埋點，同時注意需要將CAT調用鏈上下文(CAT Context)向後臺傳遞(一般以HTTP Header方式)。
- 後臺服務的入口和出口：在每個後臺服務的入口點，都需要用CAT埋點，注意在入口埋點時需要先恢復CAT調用鏈上下文，這樣上下游調用鏈才能串聯起來。在每個服務的出口點(如果有對其它服務進行調用的話)，同樣需要用CAT進行埋點，同樣也要向後傳遞CAT調用鏈上下文。
上述埋點應該儘量集中封裝，提供封裝好的框架給業務方直接用，降低業務方接入CAT的複雜性，儘量避免業務方直接埋點。
五、Hystrix的線程和信號量隔離的優劣以及試用場景
信號量隔離，優點是輕量，無額外開銷，不足是不支持任務排隊和主動超時，不支持異步調用，適用於：
- 受信客戶：比如內部服務調用我們一般認爲是受信的，而第三方服務我們不確定其性能，一般認爲是不信的。
- 高扇出：所謂高扇出就是一個服務要調用很多(幾十甚至上百個)其它服務，網關就是這種場景，需要調用很多後臺服務，如果每個後臺服務調用都用一個線程池隔離，開銷就非常大，所以適合信號量隔離。
- 高頻高速調用：例如對於緩存的訪問，一般是高速高頻，適合用信號量這種輕量隔離機制。
線程池隔離，優點是支持排隊和超時，也支持異步調用，不足是線程調用會產生額外的開銷，適用於：
- 不受信客戶：比如調用第三方服務，可能很慢，可以用線程池隔離。
- 有限扇出：如果內部服務調用扇出是有限的，一般不超過十個，可以考慮用線程池隔離。