http://dbaplus.cn/news-141-1815-1.html?utm_source=tuicool&utm_medium=referral
今天分享講的和API架構相關，餓了麼API Everything框架建設是一個不斷演進的過程，借這個機會跟大家分享一二。
1
什麼是API Everything
API這一塊不知大家有沒有什麼瞭解，所以這裏先簡單介紹一下API，就是相當於前端比如Web訪問到後端的服務接口，這中間有一個隔離，適配給外部各端進行訪問，隔離是起到安全性的考慮，還有一個協議轉換的考慮。當然，基於這一塊我們還有很多其它的考慮。在餓了麼初期發展階段，我們的很多Web API層都是手寫的，即多數應用服務後端，都自己寫Web API，單獨部署，提供給前端HTTP API調用。
當時業務高速發展，爲了快速應對，有一些業務邏輯會放在Web API層，甚至在Web API層也會訪問數據庫，進行數據庫操作。在API層直接訪問數據庫會導致安全性的一些問題，這個是不允許的。前端訪問後端，這個HTTP API接口是什麼風格的，有是Restful的，還有JSON-RPC的，需要統一考慮，不然對前端開發的體驗不一致。另外HTTP API文檔存在過時，不能反映代碼實現的變化，比如代碼改了，文檔沒有改。最後，前端同學和後端同學同時開發，但開發的節奏可能不太一樣。比如前端在進行開發，但後端可能會被插入更加緊急的項目，就不能及時完成當前項目的API，可能會延誤前端的開發，產生前後端開發不同步，導致前端資源和後端資源有個相互等待，會導致開發體驗的不順暢，效率也不高。
2
需求調研-API Everything
API
基於這些情況，公司考慮是否可以統一形成一個框架，於是我們調研了各個部門，發現他們有這個需求，希望有一個統一的API框架開發，目前也有一些獨立寫的Web API 層。下面是調研的一些需求：
我們能看到一個很重要的功能就是HTTP到SOA的服務映射，還有認證與鑑權，比如公司的SSO，包括用戶、餓了麼的一些鑑權，API部署與運行。
API Orchestration，這個相當於說API的拼接和剪裁的概念，即可以調用多個API，取各個API返回結果的一部分，重新組合成新的結果，返回給前端。這個應用在一個前端API調用，可以實際調用多個後端API，組裝一個返回結果給前端，減少前端調用後端多次，提高前端用戶的體驗。另外，因爲後端已經有了很多基礎服務的接口，新業務開發不需要後端再提供接口，只需要在這些接口上進行組合、裁剪就可以了。
此外還有API文檔、API測試、Mock API、限流、反爬（就是說把接口曝露在公網，存在爬蟲爬取這些接口的情況，我們怎麼保護接口等等）以及灰度。我們的API Everything做這些事情時，把後端的SOA服務通過API的方式，安全可靠地提供給各種端(Web/APP)來使用。
3
產品技術方案原則
調研出來以後，需要考慮以什麼原則去考慮產品和系統設計。
APIEverything是一個基礎框架，我們首先考慮到基礎框架穩定性是第一的，哪怕你不能滿足所有功能需求，但你很穩定，接入API Everything框架的各個應用系統就不會歇菜，不出問題，服務才能在穩定的基礎上提升，纔有可能增加新的功能和特性，也就是說穩定壓倒一切。然後是性能，包括吞吐量（響應速度）、性能高了，就會節省硬件資源；高可用性，避免出現單點故障。還有容錯性，對外各種依賴，要考慮外部依賴歇菜怎麼辦，怎麼降級。還有，API Everything接了後端的應用系統，外部流量進來，不能衝擊到後端應用系統。如何讓這個系統更健壯，怎麼保護自己，怎麼保護接入的應用系統等等。
其次，在這個基礎之上考慮DevOps怎麼弄，提供接入方自助DevOps，還有各種指標查看、監控告警、排錯手段、查看log/trace/exception、自助擴容等。最終希望這一塊做到對接入方是透明的，可以自動擴容。API Everything框架引起的問題，由我們解決，接入應用方出現的問題，由接入方解決，要有非常清晰的邊界界定。一般問題可以自動解決，現場日誌自動保留，儘可能自愈。並且接入方知道發生了什麼情況。
另外，就是怎麼讓我們的研發或者應用開發端更“懶”，就是把經常要做的事情自動化，比如接入一個應用方，要進行各種配置，比較繁瑣也容易出錯，那我們是不是可以進行自動化接入、自動化配置呢？
剛纔也談到代碼和文檔不同步怎麼辦，所以我們不寫文檔，在代碼裏面寫文檔，比如：在Java代碼裏寫Java doc註釋，我們就把這些註釋抽出來，作爲API文檔的一部分。另外，我們也提供一些標註，幫助完成文檔。
用戶體驗也是考慮的一大因素，因爲技術產品基本上由工程師直接進行開發，追求完成功能，多數沒有考慮用戶體驗，導致用起來操作別扭。所以在這方面要充分吸取教訓，把使用者的體驗考慮起來，能點一下就可以的，就不用點兩下。不能把技術複雜性暴露給用戶去理解、去操作。讓用戶用起來很爽，簡單不去操作是一個目標。這個框架涉及到很多配置，散放在不同系統，我們的想法是在一個配置裏面全把它搞定，不要讓用戶理解這個是API Everything框架的哪一部分管理的，要到哪個系統去操作。另外就是滿足不同的功能需求，比如接入不同的協議等。這是我們對整個產品方案有些原則上的考慮。
4
生命週期
從API這邊出發，可以看到API的生命週期是從API開發開始的，這個過程中會有文檔、Mock，開發完了是管理，也就是授權誰能訪問，有些是不是可以灰度。API管理之後是API網關服務，就是運行態服務，對API進行協議轉換，比如將HTTP 協議轉換成SOA，調用後臺的SOA服務，最後進入API運維，就是對API進行監控管理和部署擴容。
5
產品規劃
根據產品系統設計原則，結合API的生命週期，我們就規劃了下面幾個產品。
比如說開發支持這一塊，就是API Portal，運行支持這塊就是Stargate Cluster。還有質量保證，就是API Robot，通過自動化迴歸測試來保證API的質量。另外要考慮到在開發的過程中，怎麼讓前後端同步，這裏面重要一點怎麼樣Mock API的數據，讓前後端分離開發，就產生了Mock Server，於是根據規劃形成了這四個產品。
但這四個產品之間是什麼樣的關係呢？這裏從系統上的交互來考慮。
基本上我們從底下看，前端的應用（比如到達圈前端），通過HTTP訪問，到達Nginx Cluster，然後轉向SOA服務。灰色的路徑就是到達圈管理後臺應用，灰色再上去就到達圈服務，另外還有紅色這條路徑，前端URL可以通過加入query string訪問Mock Server， Stargate Cluster收到這個querystring，就不會發給後端SOA服務，會路由到指定的MockServer。前端會通過Mock的方式完成前端的開發。
API Portal負責API文檔這塊，文檔對應的是部署到哪個環境，在API Portal裏有顯示。在餓了麼有幾個環境，一個是開發的Alpha測試環境，提供給開發使用的。還有一個是Beta環境，是提供給測試來驗證是否可以上線的環境，只有通過了Beta測試，才能上線。這個Beta環境也用來和其他團隊進行聯調。最後是Prod環境，用於線上生產。在API Portal上就能知道當前部署的應用，對外提供的API文檔具體是什麼，這是API Portal通過訪問Stargate Cluster部署信息獲得的。
API Robot從API Portal中獲取API定義，通過定義發測試請求給Stargate Cluster。
餓了麼內部服務是SOA架構，服務間有相互依賴的情況，需要進行測試、聯調。有時候發現我們SOA服務依賴對方SOA服務，對方還沒有開發完成，我們想測試自己開發 的SOA服務怎麼辦？這時我們就可以用Mock Server，Mock 對方的SOA服務，寫一下Mock Case，完成我們自己的 開發測試。
剛纔說代碼即文檔，所以可能要規範一下怎樣寫代碼，註釋和標註寫完了，就可以自動化從這些註釋和標註中抽出文檔，形成API文檔。Web API這一塊不需要手工寫，目前我們自動生成對應Web API的代碼，然後自動再部署。部署就是監聽SOA服務部署消息，收到了部署消息，就自動生成的Web API代碼並且自動部署。而Mock，我們也是自動生成的，創建Mock Case的時候，就自動生成相應的數據，這些數據可以自己改。還有API的監控告警，每個應用接入，自動進行全鏈路監控。
6
Stargate Cluster技術架構
這是其中一個產品Stargate Cluster的技術架構。從上面看，ELESS是我們構建系統，我們會監聽它的構建消息，當有構建過來的時候，調用base.stargate_core服務，該服務實現非常簡單，就是把StargateCluster需要的信息保存到MaxQ裏面，MaxQ是餓了麼自己開發的一個MQ產品，目前在大量應用。最後Stargate Cluster運營管理服務是從MaxQ取消息進行處理。
爲什麼會有這樣的考慮？因爲之前我們在Stargate Cluster運營管理服務裏經常有迭代開發，經常增加一些功能（比如異地多活），這些功能不斷地迭代、增加，需要經常部署，處於一個不太穩定的情況。我們想任何這種構建和部署消息不能丟，於是就有了 stargate_core這個服務，這個服務非常簡單，不進行功能上的迭代，保持不變，這樣就比較可靠，作用就是把構建和部署消息放在MaxQ裏頭；而stargate運營管理不斷開發、然後重啓，這個過程中至少MaxQ裏的數據不會丟，重啓完了也可以消費，繼續進行部署。我們是基於變化和不變化的隔離去考慮系統可靠性的結果。
Stargate Cluster基於Docker部署
談談爲什麼能自動部署？其實挺有意思的，我們這邊用的是Docker環境。從底下開始看，可以看到比如SOA服務部署了，通過ELESS(餓了麼發佈系統 ），我們獲得部署消息，放到MaxQ裏，我們從MaxQ拿出消息，調用AppOS（餓了麼自研的Docker平臺），啓動相應的Docker實例，實例上運行着這個SOA服務 對應的Web API代碼 ，Docker實例啓動時，調用Navigator（餓了麼自研的Nginx管理平臺），將該Docker實例的IP註冊到Nginx上，這樣外部流量就打到這些Docker上了，在新Docker成功啓動之後, Stargate Cluster就會調用Appos 將之前版本的Docker實例給銷燬掉，通過Navigator 將對應在Nginx上的IP也刪除掉，這就是完成自動部署。
這是我們自動部署的一些信息，可以看到左上角基本上是SOA服務部署的Push Seq，下面是PushSeq Used by Client， 這兩個Push Seq一致，就說明SOA服務部署時，Stargate Cluster將其對應的Web API端也自動部署了，兩邊用的版本(Push Seq)是一致的。同時，包括部署的一些版本信息我們也都會保存下來。
7
API Portal – 自動化文檔
講完Stargate Cluster，我們看看API Portal這一塊。 API Portal在系統部署時，獲取部署的源文件，自動解析這些代碼，然後根據代碼裏面的註釋和標註自動生成API文檔，這個文檔以Swagger方式存儲。剛開始我們以Swagger的原生界面去展示這個界面，前端開發不太習慣這個界面，於是我們就用前端喜歡的，即作爲各種表格進行展示來給他們使用。上面的表格展示方式，就是因爲這個開發出來的。
那Swagger原生的界面還需要嗎？API Portal上有一個功能， Try it Out(就是試一試），具體就是後端開發採用這個功能看看後端API吐的數據長得怎麼樣，不對就修改後端API，直到滿意爲止。前端也使用這個功能，看看沒有實際數據又是怎麼樣的。Try it Out功能就採用了Swagger原生的界面，後端反而比較喜歡這個頁面，因此保留下來。這樣前後端的用戶體驗，也都能滿足，大家各取所需。下面是一個Swagger文檔界面：
8
Mock Server 流程
MockServer是什麼？看看這個場景，SOA Client要對Service Provider進行測試， Service Provider （就是被測試的對象Server Under Test ）依賴外部的服務比如Server Cluster 1，但是外部的服務因爲其它情況不能用，我們就用MockServer來模擬Server Cluster 1，這樣依賴問題解決了，SOA Client 對 Service Provider就能正常進行測試了。使用Mock Server還可以解決，依賴服務需要返回特定的場景，但又不好操作，這樣通過MockServer，寫不同的Mock Case進行返回，就比較方便。
實際情況下SOA環境裏面有很多依賴關係，但對方的接口沒有確認或者環境不好怎麼辦？我們通過Mockserver把這些服務全部屏蔽掉，這樣只需要測試我們要測試的服務就好，這對SOA環境解決依賴問題，是挺有效的。
Mock Server—自動解析
餓了麼有Maven私服，各個SOA服務之間通過Maven私服上的API進行調用。上面是我們的Mock Server界面，可以看到左邊是輸入依賴服務的接口Maven依賴，基本上操作就是延續之前SOA調用的一些流程，把外部依賴填到上面的框裏頭，在Mock Server指定依賴的接口，於是Mock Server就能從Maven私服去拉這些依賴，自動分析它到底有哪些類，分析好這個類，包括這個類裏面有哪些方法都全部顯示出來。上圖右邊的方法就是自動分析。黃色標識的那個方法，就是想進行Mock，點擊下右邊的加號，就創建了Mock Case。這個Mock Case名字就是測試任意參數。
自動生成Mock Case
MockCase是說當Mock Server接收的數據，即請求的參數和Mock Case裏設定的Input匹配，那麼這個Mock Case裏設定的Output就作爲響應返回。剛纔創建了一個Mock Case叫做測試任意參數， Mock Case的值是根據分析的Model（數據定義），自動生成。比如Input "type" : Integer，我們沒有加入enum[234567]的時候，就意味着只要是請求裏包含任何整數，該Mock Case就會被命中，返回Output的內容。如果加入了enum [234567]，那麼只有請求參數裏是234567，該Mock Case纔會命中。
Output支持函數，上面Preview 就可以看到執行Output的表達式之後是什麼結果，當該Mock Case被命中時，這個Preview的結果就作爲響應返回。
前後端開發分離
後端開發根據PRD，通過在代碼接口裏添加標註和註釋，就完成了API定義，把代碼check in，構建系統知道這個變化，這個變化通知到API Portal，就自動生成了API文檔，後端在API Portal上通知前端，雙方通過API Portal討論確認API文檔。前端根據這個文檔，通過API Portal上提供的Mock，完成前端的開發，更復雜的交互需要構造後端API產生不同的數據。前端通過構造不同的Mock Case，完成這些複雜的開發。開發完成之後，就去進行其它事情，在後端完成API開發之後，通知前端一起進行聯調。在以前，前後端不分離的話就會相互等待。前端開發等後端實現API，吐出數據之後再進行，對前端開發體驗不好，現在這樣前端就可以一氣呵成把它開發完成，不用等候後端了。現在，後端這邊也開發完了，說一個時間大家聯調一下就OK了，這就是整個前後端開發分離的流程。
應用實踐
這個流程在我們配送範圍的項目裏已經實際應用起來了，這裏我們給出了一個迭代的統計，這個迭代可以在開發的過程中就看到使用的情況，比如原來估計工時5天，現在3天就做完了。後端也節省一下時間，以前他們說不然就等前端調用後告訴他們什麼樣子，或者他自己寫一些測試腳本去看是什麼樣的數據，這方面他就寫了API，通過API Portal就能看到後端API吐的數據是否正確，這樣的話後端開發也減少了開發時間。還有，後端以前要寫Web API代碼，還要進行部署，現在也不用寫了，也不用部署了。以前聯調時間都比較長，是兩天時間，因爲其實那時聯調是包括開發時間，他不確定數據對不對，所以有些處理還沒有寫，等他看到數據以後再去開發出來，那時間稍微長一些。聯調的時間，只需半個小時，看這個事情通不通就好了，整個開發體驗還是不錯的，總體來看，整個開發時間減少了50%左右。
問題真的解決了嗎？
有了這些產品，我們看最早提到的那些問題是不是都解決了。假如今天寫業務，我們是通過統一的方式介入，把它下沉到SOA，因此業務也不會分散到各個地方。我們在定義API時也給了一個缺省的API生成方式，就是使用Json RPC，自動將方法簽名等作爲URL。另外也提供了Mock服務，幫助前後端開發分離，還有就是代碼即是文檔這一塊。然而這些問題都解決了，真的解決了嗎？其實還遠遠沒有，還有更多事情要解決。
1、全鏈路環節比較多，出現問題時如何快速定位？
2、故障發生時：
-
能夠自動把現場保留下來嗎？
-
能夠執行基本分析，把分析的結果保存下來嗎？
-
能夠自愈嗎？
3、能夠快照後臺服務及數據，通過Docker環境，通過之前記錄的traffic，自動化完成迴歸測試嗎？
4、採用Async Web，提高性能？採用GO?
5、當有一些業務需求：
-
現有API相互組合就可以完成這個需求，還是需要開發？
-
需要智能分析所有API業務屬性嗎？
-
需要面向業務開發需要提供搜索和推薦？
9
關於團隊思考
我們一直在想，面向開發、測試、運維角色，如何提供一個更好的服務，也就是說怎麼樣更懶，更自動化。比如在API的運維上，我們能不能做到對於接入用戶方完全無感知。
還有就是我們的API Everything團隊，面對多個接入方同時進行，我們應怎樣處理，自動化？其實我們不希望太多重複的事情重複去做，而是考慮怎麼通過工具把我們自己給解放出來，去做更多自動化的事情。首先解放自己，才能拯救用戶。
最後我們也希望從根上去思考問題，去解決問題，如果大家對API有什麼疑問，建議，對於API架構有更好的想法，或者想加入我們，一起來推進API或者框架開發這塊，可以聯繫我們（聯繫方式：[email protected] [email protected]），謝謝！
↓↓↓點這裏下載本文乾貨PPT
https://pan.baidu.com/s/1boKhXiJ