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