Chat三人行之微服務怎么玩

2017年3月6日周一晚8點半，進行了以“微服務化實戰(zhàn)案例分析”為主題的交流活動。本場Chat由莊表偉提供實際案例，由王淵命、肖德時、陳皓（左耳朵）共同分析、診斷，希望能夠通過更加貼近實際的討論，給大家?guī)砀嗟膯l(fā)。以下是主持人赫陽整理的實錄，記錄下了問答的精彩片段。

莊表偉，華為公司內(nèi)源社區(qū)平臺架構師，開源社理事。

王淵命，QingCloud 容器平臺負責人，前新浪微博架構師。

肖德時，曾任Redhat Engineering Service部門內(nèi)部工具組Team Leader，是國內(nèi)第一代 Docker 代碼貢獻者。

陳皓（@左耳朵耗子），前阿里和亞馬遜的技術主管。GitChat技術顧問，本場Chat特約嘉賓。

莊表偉：這個案例，是我在工作中遇到的具體的問題，我們在公司里，需要建設一個內(nèi)部的“開源社區(qū)”，大家可以理解為一個面向華為內(nèi)部員工共同使用的Github。從2013年底開始建設，到現(xiàn)在3年多的時間。在當時，我們能夠選擇的基礎平臺，其實非常有限，最合適的，也就是Gitlab的開源版本。至于后來出現(xiàn)的Go的Gogs、PHP的Phabricator，當時都還沒有，再加上我對Ruby也比較熟悉，就自然選擇了Gitlab。而Gitlab，是一個Rails的項目，因此我們的平臺，原生就是帶著Rails基因的。

華為目前的研發(fā)人員，超過8萬人，另外還有數(shù)量非常多的外包團隊，因此，要提供一個足夠供他們使用的平臺，分布式架構是一個必然的選擇。隨著Docker與微服務技術的逐漸成熟，對于Gitlab的微服務架構改造，也就成為我們思考的重要問題。

這是目前Gitlab的架構圖，不過我們在對Gitlab做二次開發(fā)的時候，還沒有Gitay這個組件。另外數(shù)據(jù)庫，用的也不是PostgreSQL，而是MySQL。

另外，https://gitlab.com/gitlab-org/gitlab-ce/blob/master/db/schema.rb 這個目前Gitlab的表結構，一共有78張表。我們在后續(xù)的開發(fā)過程中，添加了不少，目前還在做梳理，大致上會保留103張表。

目前對于數(shù)據(jù)庫中表的分類主要包括：

Platform：平臺的大多數(shù)其他表。

Project：與組織、項目相關的所有信息，這一類下面還有2個子類：

Code：與代碼相關的各種信息。

Issue：與Issue相關的各種信息。

另外我們的擴展還包括一些表：

Group： 與討論組相關的各種表。

Social：與社交行為相關的各種表。

所以，初步的想法是從大的平臺中，分離出：Project、Group、Social三類服務，剩下的留著不動。

問：監(jiān)控系統(tǒng)如何監(jiān)控自己？如果監(jiān)控自己都沒有很好的運作，那么當我們談到調(diào)用鏈監(jiān)控的時候是不是存在不確定性？

肖德時: 這是用健康檢查機制來保證的，壞了會報警。

王淵命：監(jiān)控與報警系統(tǒng)其實一般是兩個系統(tǒng)，報警系統(tǒng)依賴于健康檢查以及監(jiān)控系統(tǒng)的輸出的數(shù)值。監(jiān)控系統(tǒng)不正常工作，頂多是發(fā)現(xiàn)問題的時候排查診斷有一定困難，但沒監(jiān)控系統(tǒng)你還是要能人肉排查的吧。

莊表偉：我也想說說我的理解：監(jiān)控也是分層次的，不同層次的監(jiān)控，是逐級往上監(jiān)控的。對于最基礎的監(jiān)控：比如機房是不是有電，這個也需要，而且一定得靠不是互聯(lián)網(wǎng)的手段來報警。

我還有一個聯(lián)想：在分布式系統(tǒng)中，多個實例的選舉機制。也是互相監(jiān)控的情況。

問：阿里云推出了容器服務，采用他們?nèi)萜鞣帐遣皇菚档臀⒎盏拈T檻？

肖德時： 我認為不會。微服務的設計和部署都很重要，但是架構設計更能體現(xiàn)價值。

王淵命：我覺得直接使用容器服務可以降低容器服務本身的維護門檻，但容器只涉及微服務的運維管理問題，至于如何架構，如何拆分，服務如何治理，還是有很多門檻的。

莊表偉：其實，我倒是想提一個類似的問題：比如完全用docker原生的技術，還是用kubernets的平臺，是不是會降低微服務化改造的難度？

陳皓：容器平臺不會降低門檻，因為微服務的重點不在PaaS，而是在自己怎么拆分自己的業(yè)務，還有自己業(yè)務的架構。微服務更多說的是業(yè)務架構、業(yè)務應用生命周期的調(diào)度和業(yè)務應用間的關系。打個比方：微服務是汽車，容器平臺是公路，公路是讓汽車跑得更好，但公路再好不會降低汽車的生產(chǎn)門檻。：）

王淵命：我是比較看好容器平臺對微服務的支持的，只是現(xiàn)在容器平臺上層的工具鏈還不夠成熟。比如服務治理，監(jiān)控，以及服務注冊，這些都可以讓渡給容器平臺的。

肖德時：解偶過程有什么經(jīng)典坑，有這么一個，就是一個服務啟動后依靠多個其他子服務。

陳皓：根據(jù)程序的本質(zhì)：程序 = 控制Control + 邏輯 Logic這個Principle來看，所謂控制，就是我們程序?qū)?shù)據(jù)和流程的控制（比如：分布式、并行等），邏輯就是業(yè)務邏輯，Control是程序復雜度的下限，而Logic是程序復雜度的上限。就是說，如果業(yè)務邏輯本身就復雜，我們是無法通過程序的手段降低復雜度的。Docker和K8S就是控制，而業(yè)務邏輯才是整個系統(tǒng)復雜度的根源。我們經(jīng)常把控制和邏輯混在一塊，導致程序或架構更加的混亂和復雜。

問：微服務化之后，系統(tǒng)管理后臺和app使用的微服務的業(yè)務代碼需不需要分開實現(xiàn)。gateway需不需要分開？

王淵命：你的這個gateway是API gateway么？這個肯定要分開的吧。但管理后臺，一種是直接用業(yè)務代碼的API，好處是只維護一套API，一套業(yè)務邏輯，缺點是需要給管理后臺做許多專門的API。

如果管理后臺單獨實現(xiàn)，直接操作數(shù)據(jù)庫，這種是比較方便，但缺點是以后數(shù)據(jù)庫升級就比較麻煩，緩存相關的處理也比較麻煩。如果團隊大了，最終會切換到前面那種方式。

提問者：是API gateway。

王淵命：還有一種辦法是管理后臺的讀操作直接讀取一個從庫，但寫操作需要通過業(yè)務api。這種管理后臺開發(fā)人員的靈活性比較高，可隨意定制，也一定程度考慮到了數(shù)據(jù)一致性問題。

莊表偉：這種搞法，似乎更累啊。

陳皓：個人覺得：不管是不是微服務，管理后臺都是要和用戶的業(yè)務分開的，從安全的考慮也應該是這樣的。

問：但是如果把管理后臺和app的功能放到一起，權限方面怎么控制，系統(tǒng)用戶和會員是放到一起，還是分開設計？因為我們做的都是一些傳統(tǒng)應用。

莊表偉：嗯，是說最后一種。

王淵命：我覺得他問的是API層，這個其實挺矛盾的。比如 user service，同時也給管理后臺輸出接口么？這個我覺得應該按照API認證和權限機制來控制。

莊表偉：在我們的系統(tǒng)里，管理后臺的任務，還不算繁重，所以并沒有特別的處理。但是，如果有非常多的管理、配置、權限之類的邏輯，似乎獨立一個管理服務，會更加妥當些。但是，這個管理的服務，應該會調(diào)用其他業(yè)務的API，而不是搞讀寫分離吧。

陳皓：從業(yè)務和安全的角度來講，像權限比較大的專人使用的API，是另一個網(wǎng)關。

王淵命：沒辦法，管理后臺的需求變化非常大，如果全部要業(yè)務團隊來輸出api，會比較累，時間上也會有問題。所以直接給個從庫搞也是一種妥協(xié)的辦法。我是按照互聯(lián)網(wǎng)應用的需求來分析的。

陳皓：我覺得不要把什么事都往微服務上來靠，微服務不核心，只是一個手段，核心是業(yè)務。所以，還是要從業(yè)務上來挑選不同的手段。

莊表偉：我插一句，聊聊我們的系統(tǒng)的思考?；旧?，我是打算，把能分的分出去。剩下的還是都放在一起。而且，之前肖德時提到的判斷標準，我覺得很有道理：有橫向擴展壓力的業(yè)務，才需要拆分出去，作為微服務。

王淵命：沒有完美的方案，要根據(jù)業(yè)務階段選擇。比如當前業(yè)務緊張，用戶需求開發(fā)團隊都忙不過來，管理后臺的需求就耽擱了，但有些管理后臺的需求又是運營團隊和管理團隊必須的（比如內(nèi)容審核 等等）。這時候就只能用一些妥協(xié)的，可能違反設計原則的辦法了。

問：商城一般后臺有系統(tǒng)用戶管理，會員管理，商品分類，商品管理，訂單管理等。商城的商品管理和訂單處理引擎之間的關系？

王淵命：我理解你的意思是，比如我們用了 用戶和訂單微服務，這個是直接面向最終用戶的api，輸出給web和app，這時候管理后臺需要管理用戶以及訂單，這部分接口和用戶的接口有部分重復，但也有一部分轉(zhuǎn)有的，這部分應該放在 用戶和訂單的微服務里，還是單獨搞管理后臺的微服務，是否共享數(shù)據(jù)庫。我前面的回答都是按照這個理解回答的。

問：我的問題主要是后臺這部分功能，在微服務里面應該怎么放，是合在一起，還是分開，如果合在一起，那么api 網(wǎng)關應不應該合在一起還是分開。因為我看了很多微服務的分析架構，但是都沒有講到管理后臺這么分怎么開發(fā)。

陳皓：我們先不說微服務，我們先說SOA，對于電商這樣的平臺，服務也需要分層次，有后端服務（如：數(shù)據(jù)model層的），也有中臺服務（如：業(yè)務和技術中間件），還有前端服務（提供給用戶的服務），對于這三個層次，后端和中臺的是可以共享的，前端的建議分開，gateway也應該分開。

商城的商品管理和訂單處理，這應該是兩個業(yè)務，我不知道你說的關系具體是什么，能具體說一下嗎？

問：商品與訂單流程引擎看上去是分開的模塊，但在運行時是緊密相關的，比如訂單處理過程經(jīng)常要讀到商品的各種特殊屬性來做不同的邏輯，所以修改商品處理流程實際上需要同時修改商品管理模塊的流程管理模塊，那么多次修改之后非常容易讓兩個模塊之間偶合得很緊，那么當初解偶到微服務的意義 就大減，那么怎么去避免這種偶合問題？

陳皓： 按我的理解，一旦訂單下了，應該對下單的商品做一個“小快照”和reference，因為商品的信息可能會經(jīng)常變化的，所以，一些和訂單的相關的數(shù)據(jù)必需要下單時持久化在訂單內(nèi)（比如：價格、折扣、商品的基本信息和基本屬性，等等），這主要是怕用戶下單時和之后的商品數(shù)據(jù)變化產(chǎn)生不一致的情況，所以需要把相關數(shù)據(jù)冗余到訂單上來。當然，訂單中心也需要反向查一些商品的信息，但是從業(yè)務上來說，這樣的情況一般來說是對不影響訂單的狀態(tài)的，所以，從業(yè)務上來說，這應該是一個從業(yè)務上來說就是松耦合的兩個系統(tǒng)。所以，其實這個還是業(yè)務問題，這就是微服務最難的地方——業(yè)務分析能力。

提問者：以我的理解，管理后臺這么錯綜復雜的東西，如果業(yè)務量不是特別巨大，那么只需要把數(shù)據(jù)庫、緩存、消息隊列等基礎服務分出去，如果某個無狀態(tài)的API業(yè)務量巨大，那么就應該把它單獨分出來能橫向擴展。

陳皓：你說的是技術中間件，還有業(yè)務中間件，也是可以共享的（比如：權限中心、短信中心、支付服務之類的）。

肖德時：商城一般后臺有系統(tǒng)用戶管理，會員管理，商品分類，商品管理，訂單管理等。我見過的大多數(shù)就是單體應用來支撐就夠了。沒有流量。落數(shù)據(jù)庫就可以了。

問：微服務接口的版本如何控制冗余比較好？比如有接口需要升級，但又要考慮對老接口調(diào)用的兼容，代碼層面如何實現(xiàn)或部署比較好，有沒有什么標準規(guī)則？

肖德時：微服務的網(wǎng)關做路由到新舊兩個版本的實例上。

莊表偉：關于這個問題，我先拋個磚，這種情況，不是一般都是在API里，加上v1,v2這樣的路徑，就可以了嗎？

王淵命：這種方式新版本的接口其實相當于一個新接口，對老接口完全沒影響。但這種做法也有成本，就是版本不好控制，有的接口新老版本是一樣的，有的是不一樣的。某一個接口需要升級新版本的時候，其他接口怎么辦？在網(wǎng)關層路由到舊接口？

我覺得大多數(shù)情況下，接口的參數(shù)以及返回值變動都不應該作為新版本，一般在代碼層作為兼容，除非有非常大的變更，需要完全重新設計API。

莊表偉：我覺得，你調(diào)用一個接口，就存在一種依賴。無論怎么處理，依賴總是個麻煩。所以：把麻煩顯式的暴露出來，還更好一些。（所以v1,v2就不錯）

陳皓：關于微服務接口的版本兼容，無論有沒有微服務都是需要考慮的。這個可以學習一下各個公司的API設計的方式和維護的經(jīng)驗，google一下也有很多相關的規(guī)范文章。

問：微服務中所有前后端交互是否都要走API gateway？

肖德時：可以走，也可以不走。看你的數(shù)據(jù)流向。開始的時候，你可以全部放到API Gateway。

王淵命：我個人認為 api gateway 是對外輸出的，服務之間可以直接通過服務發(fā)現(xiàn)互通。

問：微服務之間是否會存在依賴關系？如何管理？

肖德時：有API聯(lián)動就有依賴，這個依賴是一種病毒。一定要優(yōu)化避免。

王淵命：會有依賴關系，我文中建議的方式是進行依賴分層，避免依賴循環(huán)。復雜情況下，你可能需要一個聚合層來聚合各服務的api數(shù)據(jù)然后組裝成最終對外輸出的結果。

陳皓：關于依賴關系，有很多pattern可以解開依賴，一種是IoC/DIP的設計思路，變業(yè)務間的依整為所有的服務都依整一個統(tǒng)一的協(xié)議。比如一個Pub/Sub的消息/數(shù)據(jù)總線（當然，這是依賴變得復雜時的玩法）。

問：關于依賴我有個簡單例子，比如發(fā)送手機驗證碼修改密碼，修改密碼這個服務我請求后，必定會聯(lián)動后面的短信網(wǎng)關服務，發(fā)送驗證碼到用戶手機上，然后讓用戶完成修改密碼這個操作。當然這只是一個例子，碰到這種業(yè)務，如何避免依賴調(diào)用？

王淵命： 你的這種依賴是正常的啊。不然要微服務何用。

肖德時：我所說的依賴是你的API服務，因為其他子API，變的不可用了。我所說的依賴是你的API服務，因為其他子API，變的不可用了。因為微服務下，很難調(diào)試。當你有幾十個微服務的情況下，調(diào)用鏈條就多了很多，你無法快速定位。所以，從API的單一原則來講，必須保障API的服務的可用性。

王淵命：依賴一個是要有跟蹤機制，另外一個是避免循環(huán)依賴。

提問者：有zipkin就可以，可惜不是dubbo里的，springcloud提供的。

肖德時：zipkin是工具，但是不是靈丹妙藥，一定要保持簡單原則。

王淵命：服務多了，很容易循環(huán)依賴，不小心一個調(diào)用，就相當于內(nèi)網(wǎng) ddos了。

陳皓： 發(fā)短信這個服務是個無狀態(tài)的服務，也就是一個什么都不知道的，別人讓我干啥我就干啥的服務。而發(fā)驗證碼這個事，是用戶認證系統(tǒng)要干的事，也就是說，用戶認證系統(tǒng)生成驗證碼，然后調(diào)用“發(fā)驗證碼服務”，而“發(fā)驗證碼服務”會調(diào)用更為公用的的“發(fā)郵箱服務”或“發(fā)短信服務”。這也是一種解耦的方式“依整于接口而不是實現(xiàn)” （接口其實就是一種協(xié)議）。

問：贊同在對于API和WEB的拆分時，model層單獨抽成服務，不過對于這種服務該怎么去建設呢，是對其他服務提供API調(diào)用還是其它的，這一塊的擴展該怎么考慮？

王淵命：model層不應該算單獨的服務吧，應該是一個 lib 由其他服務依賴吧？model其實可以理解成服務之間的數(shù)據(jù)傳輸?shù)?schema。用 protocolbuffer 定義然后各服務自己生成也一樣吧。

問：器編排系統(tǒng)開放給應用開發(fā)人員使用時，?比較成熟的權限管理方案嗎？Gitlab后端采用的網(wǎng)絡文件系統(tǒng)選型時有考慮過glusterfs嗎？為什么最終采用了nfs呢？優(yōu)秀實踐能稍展開分享下嗎？

肖德時：這個問題好幾個串起來，我回答容器編排加權限，這塊目前都是自研的。用成熟的方案就可以，比如Django。

莊表偉：分2個部分。第一個部分關于權限的，我也想了解。先回答后一個部分。因為git是一個配置庫，如果有些文件缺失，會導致整個配置庫的數(shù)據(jù)錯誤。不像普通的分布式文件系統(tǒng)。我們可以等等，晚點再看。所以，git的配置文件的同步，我們現(xiàn)在就是使用git自己的同步協(xié)議。因此，想來想去，沒法用現(xiàn)成的分布式文件系統(tǒng)。

問：對于服務間的通信請問應基于哪些考慮來選擇REST還是rpc，且服務間的通信需要考慮哪些安全信息？

王淵命：我覺得有幾個考量標準：

qps以及接口輸出，如果非常大的量級，rpc還是有優(yōu)勢的。

開發(fā)語言，如果開發(fā)語言有不支持 rpc 的，只好用 REST 了。

另外 rpc 庫一般都支持服務發(fā)現(xiàn)中心，直接通過 smartclient 模式互相直接連接，以及進行流量切換，REST 一般還是需要個 lb來做這個事情。

肖德時：restful可以，遇到性能問題在rpc，內(nèi)部數(shù)據(jù)調(diào)用用rpc合適，但是年輕程序員不一定能搞定protobuf之類，還是用httprestful.可以。安全，有jwt之類，很多方案，沒有什么特別的。

陳皓：任何事情都是trade off， RPC有很多問題，且不利用服務的各種調(diào)度。但是RPC可以提高性能，所以，建議使用RPC時，最好不要使用很長很長的鏈接，而且需要使用一個RPC的中件間或proxy。

問：想請問一下，什么的樣的場景適合微服務？大家的判定標準是什么？

肖德時：分布式場景下才會有這個問題，比如我做的容器云平臺，底下是分布式系統(tǒng)，所以我就利用這個微服務加快構建體系。這個叫因地制宜。還有一種是當單體業(yè)務或者SOA的業(yè)務依賴太重了。期望加快一個單體應用中的一個功能的水平擴展的時候，就可以考慮加入微服務模塊。

王淵命：一般是縱向伸縮出現(xiàn)瓶頸的時候才需要微服務化。還一個笑話說，如果你的幾個團隊互相看不上，你就得拆成微服務了，也就是團隊協(xié)作原因。

問：現(xiàn)在Docker只是讓部署更快吧？和解偶沒關系，那么解偶過程有什么經(jīng)典坑可以分享一下？

陳皓：Docker的強項除了環(huán)境部署，環(huán)境隔離，還有集群調(diào)度（自動化調(diào)度的前提是自動化部署），Docker和業(yè)務解耦沒什么關系。業(yè)務解耦好處很多，我做業(yè)務這么多年，解耦最大的坑就是“程序控制邏輯會比較復雜，尤其是業(yè)務的流轉(zhuǎn)狀態(tài)”，我看到很多公司都把一個訂單的狀態(tài)機放到了各種不同的模塊里去，結果每個模堆塊維護整個狀態(tài)機的一部分，最終導致狀態(tài)混亂，各種bug和問題，這應該是最大的一個問題。要解決這個問題，其實是另一個話題了，可以放在以后的chat中講。

問：如何來設計微服務之間的訪問和通信是采用同步還是異步的原則，同步和異步訪問有比較好的介質(zhì)么（中間件）？

王淵命：同步模型就是通用的 rpc/rest模式，異步模型一般是 actor 模型。有許多現(xiàn)成的框架。

莊表偉：關于同步、異步的理解：“如果沒有實時的業(yè)務壓力，能夠異步的就異步”，我這樣說對嗎？

提問者：我覺得非必要，不要搞太多異步的，異步帶來出錯難跟蹤，就這一個問題就可以搞死人。

王淵命：除非有好的 actor 框架把復雜度屏蔽了。

莊表偉：嗯，我也是拋一個觀點來大家聊：假設已經(jīng)有一個很穩(wěn)定的消息隊列+任務總線呢？是不是會更加自然的把任務丟到異步的隊列里去？

提問者：現(xiàn)代系統(tǒng)本身都是消費者遠多于CPU數(shù)量的，異步帶來消費者不需要等待，但worker線程這個最費資源的單點沒解放出來。除非是用戶不想等待，否則不要經(jīng)常引入異步機制。

肖德時：假設已經(jīng)有一個很穩(wěn)定的消息隊列+任務總線呢？是不是會更加自然的把任務丟到異步的隊列里去？ 肯定會。銀行的業(yè)務百試不爽，天天再用。因為到后端以后，銀行的業(yè)務并不是高并發(fā)容量。所以不需要微服務。但是，隨著互聯(lián)網(wǎng)業(yè)務出來后，就不行了。

王淵命：異步隊列這種和前面說的微服務場景不一樣，異步隊列這種寫入就算成功了，不會等待結果。如果微服務的遠程調(diào)用做成異步的，調(diào)用后，對方是要異步通知到調(diào)用方的。場景不一樣。

肖德時：怎么講，業(yè)務量真正的擴大了。異步解決不了業(yè)務上的一個完整交易。必須一次性完成。這個就瞎了。所以你會看到很多金融的業(yè)務在不斷的當機中度過難關，找互聯(lián)網(wǎng)企業(yè)找方案借鑒。

問：工作流引擎作為基礎模塊，應該是可以作為單獨的微服務的，但相關的業(yè)務又是在另外的微服務中，但工作流流轉(zhuǎn)過程中要頻繁的調(diào)用業(yè)務的微服務，而業(yè)務邏輯中也有可能調(diào)用工作流的服務，這其中涉及的性能問題和事務問題如何平衡？或者說這種拆分是不是有問題？

肖德時：首先這里就是循環(huán)依賴了。微服務已經(jīng)起不到效果。要保證業(yè)務邏輯的設計不要循環(huán)依賴。應該在一起的就放在一起。別搞微服務。你可能都不需要擴展實例。

假設已經(jīng)有一個很穩(wěn)定的消息隊列+任務總線呢？是不是會更加自然的把任務丟到異步的隊列里去？ 肯定會。銀行的業(yè)務百試不爽，天天再用。

因為到后端以后，銀行的業(yè)務并不是高并發(fā)容量。所以不需要微服務。但是，隨著互聯(lián)網(wǎng)業(yè)務出來后，就不行了。 怎么講，業(yè)務量真正的擴大了。異步解決不了業(yè)務上的一個完整交易。必須一次性完成。這個就瞎了。所以你會看到很多金融的業(yè)務在不斷的當機中度過難關，找互聯(lián)網(wǎng)企業(yè)找方案借鑒。

陳皓：正好我在Amazon工作過，Amazon是個超級喜歡Workflow的公司。Workflow的微服務的實現(xiàn)，可以參考Amazon在AWS上的SWF - Simple Workflow。簡單來講這個Service有如下幾個組件供你參考：

1）Workflow: 這個東西就是引擎，其用來記錄整個工作流當前的工作歷史，并把工作流執(zhí)行的歷史和相當?shù)臄?shù)據(jù)上下文發(fā)送給Decider，這個組件也是無狀態(tài)的。

2）Decider：這個東西分析Workflow傳過來執(zhí)行歷史和相關的數(shù)據(jù)上下文，并根據(jù)用戶定義好的流程來做出下一步應該做什么的決定，并把決定交給Workflow。

3）Worker：各種各樣的干活的Worker，完全無狀態(tài)。定期的以long poll的方式從workflow拉取要干的活，并回傳結果。

問：有關api網(wǎng)關一個問題，是否除了鑒權，sso的功能也放在網(wǎng)關做，目前如果要支持原生app的權限，是否只能用token-base方式還是繼續(xù)用傳統(tǒng)的cookie-base方式？另外一個問題，本人一直覺得使用rpc開發(fā)微服務是種非最佳實踐的方式，那么在微服務體系中是一定要有rpc，還是可以不采用？不采用的話我們該如何做？

王淵命：我覺得網(wǎng)關做鑒權沒問題，但sso這個本身應該是個服務吧，不應該是網(wǎng)關的。app 一般肯定是 token 機制啊，cookie是瀏覽器的機制沒辦法，app又不受這個限制。rpc 可以看前面關于 rpc 和rest的分析吧。

陳皓：1）API的鑒權設計有很多方式，這個其實和API的設計有關系，也和安全有關，個人覺得這個話題放到未來的API設計中去吧。

2） RPC是不是微服務的最佳實踐，我給兩個不同的案例：Amazon內(nèi)部是拒絕RPC的通通走web service，而且Amazon是喜歡pull模型而不是push模型。阿里內(nèi)部是喜歡RPC的，因為需要性能，而且中間件一開始也用push模型，但后來變成了pull模型。 （我個人喜歡Amazon的方式。）

陳皓：兩個小時就這樣過去了。大家的問題還有很多，我們不可能回復這么多的問題。很感謝大家的問題和討論。我也是第一次做這個事，所以，有點喧賓奪主，三位嘉賓見諒了。在這里我簡單總結一下：

業(yè)務上的分析和解耦能力

相關的軟件設計的基礎

還是性能優(yōu)先，還是高可用優(yōu)先……這樣才能設計出合理的架構（個人建議應用的拆解應該先從不同的業(yè)務分離開始，然后進化到業(yè)務中間件的出現(xiàn)，再到技術中間件，然后再到SOA。）只有當我們的業(yè)務架構進化到了可以微服務的時候，才能開始進入微服務的領域。

（以上內(nèi)容轉(zhuǎn)自GitChat，版權歸GitChat所有，轉(zhuǎn)載請聯(lián)系GitChat，微信號：GitChat，原文：《Chat三人行之微服務怎么玩》）

本文轉(zhuǎn)載自異步社區(qū)。

API 微服務

版權聲明：本文內(nèi)容由網(wǎng)絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權內(nèi)容。

版權聲明：本文內(nèi)容由網(wǎng)絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權內(nèi)容。