摘要:最近呢,在做的設計對于設計,一方面是對于后端框架的設計,另一方面呢,是對于整個體系的設計在這里呢,我們來理理思路,先來大致分一下塊風格就不用說了,我們就用風格,接下來,也就是我們所說的接口描述語言框架,整個服務的核心驅動版本控制還有一些輔助
最近呢,在做 api 的設計
對于設計,一方面是對于后端 server 框架的設計,另一方面呢,是對于整個 api 體系的設計
在這里呢,我們來理理思路,先來大致分一下塊
風格就不用說了,我們就用 restful 風格,接下來:
IDL,也就是我們所說的接口描述語言
server 框架,整個 api 服務的核心驅動
版本控制
還有一些輔助工具,比如說,自動化工具、認證授權、監控上報、日志記錄、檢索等等
然后呢,我們就來分別說說設計開發中的一些感觸
IDL顧名思義,IDL 是我們整個 api 體系的核心模型,基本上所有的東西都是要基于我們的 IDL 的,在使用的選擇上有很多,比如 Yaml、Json、xml、PB 等等,這些都可以作為接口描述語言,同時呢,各有優劣,在這里呢,我們考慮了以下這幾種:
Json:Json 是一種穩定并得到廣泛應用的序列化格式,瀏覽器包含對該格式的原生解析能力,瀏覽器內建調試器也能很好地顯示這種內容。唯一不足在于要具備 Json 解析器/序列器,好在基本所有語言都已提供。使用 Json 最主要的麻煩在于每條信息會重復包含屬性名,導致傳輸效率低下,同時呢,Json 對于一些 api 開發過程中可能出現的特殊需求可能會處理不好,比如說,字段之間的依賴關系,就不容易描述出來
Yaml:使用 Yaml 來定義我們的 api 模型的話,可謂是非常的簡潔明了,但是對于 api 模型中的一些復雜結構,以及一些字段的自檢測,并不能夠很好的支持,同時,這個格式也不容易在開發中進行約定,可能會引起一些不必要的麻煩
PB:PB 全稱是 Protocol Buffers,是谷歌創建的一種基于二進制連接格式的接口描述語言。在解析和網絡傳輸方面 Protocol Buffers 更高效,并經歷了谷歌高負荷環境的考驗,不足在于一些語言的支持并不是很好,主要還是對于 C、python 和 java 的支持,并且呢,在 .proto 文件的共享和編譯方面會產生些許額外開發負擔
xml:這個大家就都非常熟悉了,相對于 Json 和 Yaml,xml 就顯得有些笨重了,但是 xml 能夠很好的應用于各種特殊的場景,能夠根據不斷的線上需求進一步的擴展,并且可以直接通過 xsd 進行自校驗,從功能上來講,或許會更加完善一些
因為 IDL 是我們 api 的核心,以后的各項業務基本都要圍繞 IDL 展開,所以需要能夠功能完善,便于擴展,并且在開發中能夠有一些自動化的工具來進行約束,so,最終呢,還是決定采用 xml 的形式
server 框架核心代碼非常的簡單,只需要寫一個 route 來實現路由調用就行了,但是,為了輔助他能夠正常的調用,我們就不得不實現更多的一些輔助功能了
可以來看一下我的基本的目錄結構
Framework │ ├── Auth 認證、鑒權模塊 │ ├── Base 基礎服務 │ ├── Client 各種端服務 │ ├── Common 公共組件 │ ├── Core 核心調度邏輯 │ ├── Coroutine 協程調度實現 │ ├── Exception 異常處理 │ ├── Http 協議實現 │ ├── Log 日志上報,監控模塊 │ ├── Pool 連接池(資源池) │ └── Resource 資源模型
同時呢,開發過程中要降低各模塊間依賴關系,就比如說,與其 new 一個對象,不如采用 set 的方式來解耦,預期繼承,不如采用組合的方式,保證各個模塊的獨立性,同時呢各模塊間又要有一個通訊通道
為了實現一些特殊的需求,我們采用協程調度來實現非阻塞 IO,當然,這里我們就需要實現一個多帶帶的服務端口監聽,就好比 swoole 或是 workerman 那樣,編寫獨立的服務進程
ok,上面也提到了,核心代碼只需要實現一個 route 路由就行了,但是在路由前后,要記得留出認證、鑒權接口,同時呢,對于運行時的異常也要及時捕獲上報,同時記入日志,方便調試
對了,除了這些 server 服務依賴,數據也要注意哦,最好是能夠在原始數據之上再多帶帶抽離出來一層數據接口層,不要直接操作原始數據
這些核心服務完成后,剩下的就是客戶端和服務端代碼,這個就可以根據實際的服務去自由發揮了,對于 api,我們也可以把客戶端代碼稱之為 SDK,同時呢,為了方便以后的開發維護,可以統一編寫自動化工具生成,對于不同語言對應的做支持
OK 了,上篇就先寫到這里吧,主要說了對于 server 框架以及 IDL 的設計選擇思路
下篇呢,會主要對于 api 的版本控制,發布,以及一些自動化工具進行一些分享
From: 一名熱愛動漫的攻城獅
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/21929.html
摘要:上一篇,講到了,最近,在做的設計對于設計,一方面是對于后端框架的設計,另一方面呢,是對于整個體系的設計在這里呢,我們來理理思路,先來大致分一下塊風格就不用說了,我們就用風格,接下來,也就是我們所說的接口描述語言框架,整個服務的核心驅動版本控 上一篇,講到了,最近,在做 api 的設計 對于設計,一方面是對于后端 server 框架的設計,另一方面呢,是對于整個 api 體系的設計 在這...
摘要:阿里巴巴的共享服務理念以及企業級互聯網架構建設的思路,給這些企業帶來了不少新的思路,這也是我最終決定寫這本書的最主要原因。盡在雙阿里巴巴技術演進與超越是迄今唯一由阿里巴巴集團官方出品全面闡述雙八年以來在技術和商業上演進和創新歷程的書籍。 showImg(https://segmentfault.com/img/remote/1460000015386860); 1、大型網站技術架構:核...
摘要:行勝于言,理論結合實踐才是王道,所以本文我將基于前面的學習方法,分享我是如何學習微信小程序的。第二個目標則需要學習小程序的插件相關接口調用,以及蟬知建站系統這邊的微信模塊代碼。 前段時間和大家一起分享了一篇關于學習方法內容《大牛與搬運工的差距——學習方法的力量》。我們將學習過程分成八步,并借鑒了敏捷開發的迭代思想,以達到自我迭代學習的效果。行勝于言,理論結合實踐才是王道,所以本文我將基...
摘要:一微服務概念微服務體系結構由輕量級松散耦合的服務集合組成。每個服務都有自己的計劃測試發布部署擴展集成和獨立維護。團隊不必因為過去的技術決定而受到懲罰。用在這里是指將相關的服務通過聚合器聚合在一起,這個聚合器就是門面。 微服務架構現在是談到企業應用架構時必聊的話題,微服務之所以火熱也是因為相對之前的應用開發方式有很多優點,如更靈活、更能適應現在需求快速變更的大環境。 一、微服務概念 微服...
閱讀 928·2021-11-08 13:22
閱讀 2853·2021-09-29 09:45
閱讀 2831·2021-09-09 11:52
閱讀 2264·2019-08-30 13:20
閱讀 3749·2019-08-29 13:28
閱讀 1366·2019-08-29 12:32
閱讀 2730·2019-08-29 11:10
閱讀 1650·2019-08-26 13:34