微服務手冊：API接口9個生命節點，構建全生命週期管理

互聯網應用架構：專一編程教學，架構，JAVA，Python，微服務，機器學習等領域，歡迎關注，一塊兒學習。

 

對於API，在平常的工做中是接觸最多的東西，特別是咱們軟件這一行，基本就是屢見不鮮了，在百度百科裏面的解釋：

API（Application Programming Interface，應用程序接口）是一些預先定義的函數，或指軟件系統不一樣組成部分銜接的約定。 用來提供應用程序與開發人員基於某軟件或硬件得以訪問的一組例程，而又無需訪問源碼，或理解內部工做機制的細節。

在不一樣系統之間，不一樣部門之間的各類對接，API就是研發人員的一個純粹性的溝通語言，雙方定義好規範、約束等進行系統之間的交互。

 

生命週期

在咱們軟件行業的領域裏面，每個軟件都是有生命週期的，從最開始的需求調研，需求設計，架構設計，軟件研發，測試，上線，試運行，運行到最後業務上，技術上跟不上時代的發展，被新來的技術人員嫌棄，後面的業務部門拋棄，至此開始結束最後到下線，這個系統就算結束了他們的生命週期。

API是一種應該性接口一樣具有了設計化、測試化的過程，這就顯性代表API其實也做爲有生命週期的存在，在現有的設計中，API生命週期分爲9種

• 設計
• 構建/研發
• 管理
• 聯調/測試
• 自動化
• 文檔/發佈
• 受權開放
• 監控
• 下線

 

設計--見文知意

一個API的造成，設計是最根本的存在，由於他的存在不僅僅是本身使用，更重要的是讓多方可使用，所以有一個規範的思想很是重要，這裏有個方法論就是--見文知意。每次看到API都能知道這個API是作什麼的，這是對開發者，使用者來講很是重要的一個方向，每個API實際上對應的一個後端服務的方法，必須有限定的出參與入參，其中出參與入參必須有嚴格的定義。

入參：有一個重要的準則就是能快速進行參數的基礎屬性的校驗，例如是否爲空，字段長度等，目前通常採用hibernate valid或者java自帶的valid來實現。

出參：出參的規範化體如今錯誤碼上，針對錯誤碼的定義須要很是明確，讓調用者能夠一眼就能看到問題的所在，目前不少API接口在進行設計的時候通常只有正確與錯誤兩個錯誤碼，平時用着沒問題，在業務發展到必定程度後會增長運維的難度，建議錯誤碼按照不一樣的類別，例如業務、技術等區分。

 

構建/研發--防範於未然

在進行了的第一步的規範化設計後，研發人員就要開始根據規範進行API接口的內部業務邏輯的設計，具體的業務邏輯由業務邏輯來作限定，這裏須要注意的就是非法參數儘量排除的API以外，須要在入口處進行判斷而且聚集不合法的數據直接報錯，不容許出如今後續的業務代碼邏輯裏面去判斷合法性，如上面所說採用hibernate valid進行操做，這些都是一個API生成的過程。

 

管理--指揮若定

每個API的誕生到最後的下線它都是可控可管理的。

版本管理：每個API從最開始發佈到後面不斷迭代發佈更新，都須要一個版本號來作限定，作到每個版本可查可追溯。

文檔管理：API裏面文檔是很是重要的存在，它是鏈接全部應用的橋樑裏面的中流砥柱，一份清晰可見的文檔是全部使用者的福報。在研發人員的世界中，最喜歡寫代碼，最痛苦寫文檔，可是若是把寫代碼變成一種寫代碼的方式呢，swagger能夠幫你實現本地化文檔也能夠實現離線文檔，仍是直接導入到yapi進行mock測試。

質量審覈：API並不是寫完就完事，若是隻是簡簡單單搞定並不按照規範走，入參map加上出參map的存在，那就要扯皮來，所以須要一我的來審覈這些才能容許上線。

狀態碼管理：因爲狀態碼是最多見的存在，所以它是微乎其微可是又是很是重要的東西，定義業務級別的狀態碼，定義系統級別的狀態碼，這些都須要進行管控起來。

迭代管理：迭代跟上面的版本有殊途同歸之妙，版本更着重於版本號的定義及生成，迭代更側重於每一次迭代的跟進管理，等價於每一次的歷史記錄。

權限管理：API並不是任何人均可以用的，須要進行受權。

服務管理：一個服務提供多個API，存在數據庫級別的1對N關係，須要這些進行分配及管理。

變動管理：API並不是一成不變的，除了版本號的變動，常常涉及到裏面的內容的管理，這些內容須要作記錄及對比。

 

聯調/測試--微察秋毫

一個好的API除了規範設計清晰及業務邏輯清晰，更重要的是必定也是便於測試的，對應的業務是否能完成，對應的系統對接是否有足夠集成，是否提供了足夠的詳細的文檔，確保了API的質量是有很是高的維護性的，這些統統在測試層進行驗證，本地化測試，MOCK測試，測試用例儘量完整。

 

自動化--進退有度

相比於上面的人工測試，自動化測試是標準化的一種設計。按照約定設定好必定的標準閾值對接口進行測試，檢驗接口是否知足咱們最基礎的性能等要求，可是自動化測試並非萬能的，什麼時候介入，怎麼介入，什麼樣的項目適合自動化測試，這些都須要咱們進行思考。

什麼時候介入：在項目的剛開始的時候不適合自動測試的介入，業務穩定性，需求變動快致使接口隨時隨地都在變化，代碼變更率很是高，維護成本很是高；到了後期後項目穩定了項目進入維護階段，此時自動化開始介入併爲迴歸測試作好準備。

怎麼介入：從自動化程度及自動化率來作切入點，雖然前期的項目並不適合作自動化測試，可是能夠選用一些穩定的，公用的進行測試。

適合項目：有意作迴歸測試，而且須要長期作支持維護的項目；壓力測試的項目；覆蓋率測試的項目。

 

文檔/發佈--十年磨一劍

這裏用十年磨一劍有點誇張了，可是相對於開發者來講，每個接口的誕生都是我都認爲那是一項偉大的存在。在經歷了前面的各類更改，測試，壓力考驗後能夠正式發佈了。每個接口在發佈後就直接跟網關對接，網關幫咱們實現統一的鑑權，過濾，熔斷，限流等操做來保護咱們每個接口的安全。

受權開放--首肯心折

不是全部人均可以訪問API接口的，不是每一個接口都是免費的，在必要的時刻須要咱們對特定的接口作受權管理，規定哪些人能夠訪問，哪些接口須要收費。

監控--指揮若定

在API運行期間，最重要的也是最重點的工做就是對接口進行監控，包括性能監控、可用率監控、調用量監控等，並生成監控報告。這些監控均可以幫助咱們從技術層面，業務層面進行分析接口的詳情狀況及指標，確保每個接口都儘量實現價值，實現接口的性能達標跟可用率達標。

下線--功成名就

到了這裏，接口基本上就是已經功成名就完成它的使命，咱們須要結束它的生命週期，有種莫名的傷感，夕陽西下，斷腸人在天涯，下線吧。

 

--END--

做者：@互聯網應用架構

原創做品，抄襲必究

如須要源碼或請轉發，關注後私信我

部分圖片或代碼來源網絡，如侵權請聯繫刪除，謝謝！