乾貨 | Api 體系架構分享（下）

上一篇，講到了，最近，在作 api 的設計

對於設計，一方面是對於後端 server 框架的設計，另外一方面呢，是對於整個 api 體系的設計

在這裏呢，咱們來理理思路，先來大體分一下塊

風格就不用說了，咱們就用 restful 風格，接下來：

• IDL，也就是咱們所說的接口描述語言

• server 框架，整個 api 服務的核心驅動

• 版本控制

• 還有一些輔助工具，好比說，自動化工具、認證受權、監控上報、日誌記錄、檢索等等

---

上次呢，講了 IDL 和 server 框架的設計思路

此次呢，來吧剩下兩個也給說說

版本控制

說到版本控制，大多數人的大腦中都必定會馬上想到 git 和 svn 吧，只惋惜，此次的主角可不是他們

雖然說 git 和 svn 雖好，對於一些項目也可以進行很好的開發，可是呢，對於某些場景，仍是有些 hold 不住的

好比，咱們來舉一個場景：

如今咱們的源碼大約有 500M，而後呢，採用的是分支開發，主幹發佈，可是呢，由於咱們是提供中間層 service 的，迭代週期很短，對於一些特殊的客戶，會時常有些特殊的邏輯處理，每一個開發者可能會有好幾個分支進行開發，這個樣子的話，對於這些特殊邏輯，特殊版本的管理就很是的不方便，並且，由於每次都要拉出來一個分支，而後改動可能很是小，這就形成了很是大量的冗餘量

因而，這個場景中，冗餘量、大量迭代版本的管理，就上升到了咱們的一個主要問題

如何解決呢？

單體代碼庫

在這裏，咱們引入一個節點（標籤）的概念，先來講一下總體思路

如今，咱們就拋棄 git 和 svn 的思想，把全部的代碼都放在一塊兒，經過控制 節點粒度 來控制總體的冗餘

首先，節點粒度咱們先設定爲以文件爲單位，同時呢，約定咱們的命名規範，文件名.節點標識.php，例如 Test.v1.php

接下來呢，就會有咱們原始的版本，在這個原始的版本里面，全部的文件都是 base 節點

全部的文件都會有一個父節點，最終都是繼承與 base 節點的

當咱們須要迭代到 1.0.1 版本的時候，咱們只要把須要改動的文件 copy 一個副本，而後按規範命名，接着只需對於這一個文件進行改動，這樣，冗餘的粒度就控制在了這個文件內

大大減小冗餘的同時，還大大的提升了代碼的複用，避免了菱形依賴，不一樣團隊間的跨團隊協做也變得更加靈活

接下來，咱們怎麼可以正常調用呢？

因此說，這種單體代碼庫須要一個路由引擎來驅動，這就要咱們根據實際狀況來實現了，能夠直接根據節點表示來路由，也能夠在中間加一層路由映射表，這就看具體需求了

同理，咱們能夠進一步調整節點粒度，來控制總體的冗餘，好比，粒度細化到接口級別

~~~~~~ 萌萌噠的分割線 ~~~~~~~~~

好了，下面就來分析一下這種單體代碼庫的優劣

優勢：

• 統一版本控制

• 普遍地代碼共享和複用

• 簡化依賴管理，避免菱形依賴

• 原子修改

• 大規模重構

• 跨團隊協做

• 靈活的團隊邊界和代碼全部權

• 代碼可見性以及清晰的樹形結構提供了隱含的團隊命名空間

可是呢，隨着代碼量的增長，也會出現如下問題：

• 單體模型讓代碼結構更容易理解，但卻讓代碼發現變得更困難

• 開發人員須要可以查看代碼庫，找到相關程序庫，並看看如何使用它們以及誰編寫了它們。這就須要有代碼搜索和代碼瀏覽工具

• 依賴重構和代碼清理輔助工具，按期對無用代碼進行清理

• 版本管理的重心轉移到了冗餘控制上

因此說呢，對於管理，咱們就須要開發一套額外的自動化工具了

具體關於單體代碼庫的細節也能夠查看這篇文章：

---

ok，關於版本控制就說這麼多，接下來就是最後的一些自動化工具以及輔助工程了

自動化工具

爲何須要自動化工具呢？

一方面，節約咱們維護開發的成本，對於一些能夠自動化的操做就不必去人工操做

另外一方面呢，也是爲了減小人工操做中可能帶來的一些失誤

就好比咱們如今的 api，都須要哪些自動化工具呢？

• SDK 自動生成工具：對於咱們提供給用戶的 SDK，咱們固然不但願每次迭代都要從新給用戶寫一份新的，因此說呢，經過自動化工具，自動生成各類語言調用的 SDK 是頗有必要的

• IDL 解析工具：咱們在讀取數據的時候，確定不能每次都去解析 IDL 的結構，這樣會帶來太多沒必要要的額外開銷，因此說呢，咱們須要提早解析 IDL 進行緩存，從而提升咱們調用的速度，而這個解析生成的過程，就交給工具來完成了

• 代碼庫搜索工具：由於咱們採用了單體代碼庫，因此慢慢的代碼愈來愈多，代碼搜索工具就變的必不可少了

• 代碼發現工具：也是爲了維護代碼庫，按期發現清理無用代碼

至於一些其餘的自動化工具，就根據你們的具體需求去實現吧，也就不一一列舉了

其餘輔助工具

好比說，認證、受權、監控、上報、日誌等等

這些在 server 框架設計的同時就都要考慮進去，何時須要上報，如何設定日誌格式從而使得咱們可以更加方便的去維護等等

對於日誌管理，可使用一些開源系統快速搭建

好比，logstash 來搭建日誌管理系統，經過 ElasticSearch 來進行索引檢索服務，而後呢使用 kibana 做爲分析和可視化平臺

---

ok，api 設計分享就到這裏

FROM: 一隻熱愛動漫的攻城獅 ~ ~ ~