資訊專(zhuān)欄INFORMATION COLUMN
摘要：上一篇，講到了，最近，在做的設(shè)計(jì)對(duì)于設(shè)計(jì)，一方面是對(duì)于后端框架的設(shè)計(jì)，另一方面呢，是對(duì)于整個(gè)體系的設(shè)計(jì)在這里呢，我們來(lái)理理思路，先來(lái)大致分一下塊風(fēng)格就不用說(shuō)了，我們就用風(fēng)格，接下來(lái)，也就是我們所說(shuō)的接口描述語(yǔ)言框架，整個(gè)服務(wù)的核心驅(qū)動(dòng)版本控
上一篇，講到了，最近，在做 api 的設(shè)計(jì)
對(duì)于設(shè)計(jì)，一方面是對(duì)于后端 server 框架的設(shè)計(jì)，另一方面呢，是對(duì)于整個(gè) api 體系的設(shè)計(jì)
在這里呢，我們來(lái)理理思路，先來(lái)大致分一下塊
風(fēng)格就不用說(shuō)了，我們就用 restful 風(fēng)格，接下來(lái)：
IDL，也就是我們所說(shuō)的接口描述語(yǔ)言
server 框架，整個(gè) api 服務(wù)的核心驅(qū)動(dòng)
版本控制
還有一些輔助工具，比如說(shuō)，自動(dòng)化工具、認(rèn)證授權(quán)、監(jiān)控上報(bào)、日志記錄、檢索等等
上次呢，講了 IDL 和 server 框架的設(shè)計(jì)思路
這次呢，來(lái)吧剩下兩個(gè)也給說(shuō)說(shuō)
版本控制說(shuō)到版本控制，大多數(shù)人的大腦中都一定會(huì)立刻想到 git 和 svn 吧，只可惜，這次的主角可不是他們
雖說(shuō) git 和 svn 雖好，對(duì)于一些項(xiàng)目也能夠進(jìn)行很好的開(kāi)發(fā)，但是呢，對(duì)于某些場(chǎng)景，還是有些 hold 不住的
比如，我們來(lái)舉一個(gè)場(chǎng)景：
現(xiàn)在我們的源碼大約有 500M，然后呢，采用的是分支開(kāi)發(fā)，主干發(fā)布，但是呢，因?yàn)槲覀兪翘峁┲虚g層 service 的，迭代周期很短，對(duì)于一些特殊的客戶(hù)，會(huì)時(shí)常有些特殊的邏輯處理，每個(gè)開(kāi)發(fā)者可能會(huì)有好幾個(gè)分支進(jìn)行開(kāi)發(fā)，這個(gè)樣子的話(huà)，對(duì)于這些特殊邏輯，特殊版本的管理就非常的不方便，而且，因?yàn)槊看味家鰜?lái)一個(gè)分支，然后改動(dòng)可能非常小，這就造成了非常大量的冗余量
于是，這個(gè)場(chǎng)景中，冗余量、大量迭代版本的管理，就上升到了我們的一個(gè)主要問(wèn)題
如何解決呢？
單體代碼庫(kù)在這里，我們引入一個(gè)節(jié)點(diǎn)（標(biāo)簽）的概念，先來(lái)說(shuō)一下整體思路
現(xiàn)在，我們就拋棄 git 和 svn 的思想，把所有的代碼都放在一起，通過(guò)控制 節(jié)點(diǎn)粒度 來(lái)控制整體的冗余
首先，節(jié)點(diǎn)粒度我們先設(shè)定為以文件為單位，同時(shí)呢，約定我們的命名規(guī)范，文件名.節(jié)點(diǎn)標(biāo)識(shí).php，例如 Test.v1.php
接下來(lái)呢，就會(huì)有我們?cè)嫉陌姹?，在這個(gè)原始的版本里面，所有的文件都是 base 節(jié)點(diǎn)
所有的文件都會(huì)有一個(gè)父節(jié)點(diǎn)，最終都是繼承與 base 節(jié)點(diǎn)的
當(dāng)我們需要迭代到 1.0.1 版本的時(shí)候，我們只要把需要改動(dòng)的文件 copy 一個(gè)副本，然后按規(guī)范命名，接著只需對(duì)于這一個(gè)文件進(jìn)行改動(dòng)，這樣，冗余的粒度就控制在了這個(gè)文件內(nèi)
大大減少冗余的同時(shí)，還大大的提高了代碼的復(fù)用，避免了菱形依賴(lài)，不同團(tuán)隊(duì)間的跨團(tuán)隊(duì)協(xié)作也變得更加靈活
接下來(lái)，我們?cè)趺茨軌蛘Ｕ{(diào)用呢？
所以說(shuō)，這種單體代碼庫(kù)需要一個(gè)路由引擎來(lái)驅(qū)動(dòng)，這就要我們根據(jù)實(shí)際情況來(lái)實(shí)現(xiàn)了，可以直接根據(jù)節(jié)點(diǎn)表示來(lái)路由，也可以在中間加一層路由映射表，這就看具體需求了
同理，我們可以進(jìn)一步調(diào)整節(jié)點(diǎn)粒度，來(lái)控制整體的冗余，比如，粒度細(xì)化到接口級(jí)別
~~~~~~ 萌萌噠的分割線 ~~~~~~~~~
好了，下面就來(lái)分析一下這種單體代碼庫(kù)的優(yōu)劣
優(yōu)點(diǎn)：
統(tǒng)一版本控制
廣泛地代碼共享和復(fù)用
簡(jiǎn)化依賴(lài)管理，避免菱形依賴(lài)
原子修改
大規(guī)模重構(gòu)
跨團(tuán)隊(duì)協(xié)作
靈活的團(tuán)隊(duì)邊界和代碼所有權(quán)
代碼可見(jiàn)性以及清晰的樹(shù)形結(jié)構(gòu)提供了隱含的團(tuán)隊(duì)命名空間
但是呢，隨著代碼量的增加，也會(huì)出現(xiàn)以下問(wèn)題：
單體模型讓代碼結(jié)構(gòu)更容易理解，但卻讓代碼發(fā)現(xiàn)變得更困難
開(kāi)發(fā)人員需要能夠查看代碼庫(kù)，找到相關(guān)程序庫(kù)，并看看如何使用它們以及誰(shuí)編寫(xiě)了它們。這就需要有代碼搜索和代碼瀏覽工具
依賴(lài)重構(gòu)和代碼清理輔助工具，定期對(duì)無(wú)用代碼進(jìn)行清理
版本管理的重心轉(zhuǎn)移到了冗余控制上
所以說(shuō)呢，對(duì)于管理，我們就需要開(kāi)發(fā)一套額外的自動(dòng)化工具了
具體關(guān)于單體代碼庫(kù)的細(xì)節(jié)也可以查看這篇文章：
ok，關(guān)于版本控制就說(shuō)這么多，接下來(lái)就是最后的一些自動(dòng)化工具以及輔助工程了
自動(dòng)化工具為什么需要自動(dòng)化工具呢？
一方面，節(jié)約我們維護(hù)開(kāi)發(fā)的成本，對(duì)于一些可以自動(dòng)化的操作就沒(méi)必要去人工操作
另一方面呢，也是為了減少人工操作中可能帶來(lái)的一些失誤
就比如我們現(xiàn)在的 api，都需要哪些自動(dòng)化工具呢？
SDK 自動(dòng)生成工具：對(duì)于我們提供給用戶(hù)的 SDK，我們當(dāng)然不希望每次迭代都要重新給用戶(hù)寫(xiě)一份新的，所以說(shuō)呢，通過(guò)自動(dòng)化工具，自動(dòng)生成各種語(yǔ)言調(diào)用的 SDK 是很有必要的
IDL 解析工具：我們?cè)谧x取數(shù)據(jù)的時(shí)候，肯定不能每次都去解析 IDL 的結(jié)構(gòu)，這樣會(huì)帶來(lái)太多不必要的額外開(kāi)銷(xiāo)，所以說(shuō)呢，我們需要提前解析 IDL 進(jìn)行緩存，從而提高我們調(diào)用的速度，而這個(gè)解析生成的過(guò)程，就交給工具來(lái)完成了
代碼庫(kù)搜索工具：因?yàn)槲覀儾捎昧藛误w代碼庫(kù)，所以慢慢的代碼越來(lái)越多，代碼搜索工具就變的必不可少了
代碼發(fā)現(xiàn)工具：也是為了維護(hù)代碼庫(kù)，定期發(fā)現(xiàn)清理無(wú)用代碼
至于一些其他的自動(dòng)化工具，就根據(jù)大家的具體需求去實(shí)現(xiàn)吧，也就不一一列舉了
其他輔助工具比如說(shuō)，認(rèn)證、授權(quán)、監(jiān)控、上報(bào)、日志等等
這些在 server 框架設(shè)計(jì)的同時(shí)就都要考慮進(jìn)去，什么時(shí)候需要上報(bào)，如何設(shè)定日志格式從而使得我們能夠更加方便的去維護(hù)等等
對(duì)于日志管理，可以使用一些開(kāi)源系統(tǒng)快速搭建
比如，logstash 來(lái)搭建日志管理系統(tǒng)，通過(guò) ElasticSearch 來(lái)進(jìn)行索引檢索服務(wù)，然后呢使用 kibana 作為分析和可視化平臺(tái)
ok，api 設(shè)計(jì)分享就到這里
FROM: 一只熱愛(ài)動(dòng)漫的攻城獅 ~ ~ ~
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://specialneedsforspecialkids.com/yun/21974.html
摘要：最近呢，在做的設(shè)計(jì)對(duì)于設(shè)計(jì)，一方面是對(duì)于后端框架的設(shè)計(jì)，另一方面呢，是對(duì)于整個(gè)體系的設(shè)計(jì)在這里呢，我們來(lái)理理思路，先來(lái)大致分一下塊風(fēng)格就不用說(shuō)了，我們就用風(fēng)格，接下來(lái)，也就是我們所說(shuō)的接口描述語(yǔ)言框架，整個(gè)服務(wù)的核心驅(qū)動(dòng)版本控制還有一些輔助 最近呢，在做 api 的設(shè)計(jì) 對(duì)于設(shè)計(jì)，一方面是對(duì)于后端 server 框架的設(shè)計(jì)，另一方面呢，是對(duì)于整個(gè) api 體系的設(shè)計(jì) 在這里呢，我們來(lái)理...
摘要：行勝于言，理論結(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í)過(guò)程分成八步，并借鑒了敏捷開(kāi)發(fā)的迭代思想，以達(dá)到自我迭代學(xué)習(xí)的效果。行勝于言，理論結(jié)合實(shí)踐才是王道，所以本文我將基...
摘要：阿里巴巴的共享服務(wù)理念以及企業(yè)級(jí)互聯(lián)網(wǎng)架構(gòu)建設(shè)的思路，給這些企業(yè)帶來(lái)了不少新的思路，這也是我最終決定寫(xiě)這本書(shū)的最主要原因。盡在雙阿里巴巴技術(shù)演進(jìn)與超越是迄今唯一由阿里巴巴集團(tuán)官方出品全面闡述雙八年以來(lái)在技術(shù)和商業(yè)上演進(jìn)和創(chuàng)新歷程的書(shū)籍。 showImg(https://segmentfault.com/img/remote/1460000015386860); 1、大型網(wǎng)站技術(shù)架構(gòu)：核...
摘要：一微服務(wù)概念微服務(wù)體系結(jié)構(gòu)由輕量級(jí)松散耦合的服務(wù)集合組成。每個(gè)服務(wù)都有自己的計(jì)劃測(cè)試發(fā)布部署擴(kuò)展集成和獨(dú)立維護(hù)。團(tuán)隊(duì)不必因?yàn)檫^(guò)去的技術(shù)決定而受到懲罰。用在這里是指將相關(guān)的服務(wù)通過(guò)聚合器聚合在一起，這個(gè)聚合器就是門(mén)面。 微服務(wù)架構(gòu)現(xiàn)在是談到企業(yè)應(yīng)用架構(gòu)時(shí)必聊的話(huà)題，微服務(wù)之所以火熱也是因?yàn)橄鄬?duì)之前的應(yīng)用開(kāi)發(fā)方式有很多優(yōu)點(diǎn)，如更靈活、更能適應(yīng)現(xiàn)在需求快速變更的大環(huán)境。 一、微服務(wù)概念 微服...
閱讀 2367·2021-11-22 14:56
閱讀 1175·2019-08-30 15:55
閱讀 3206·2019-08-29 13:29
閱讀 1354·2019-08-26 13:56
閱讀 3484·2019-08-26 13:37
閱讀 558·2019-08-26 13:33
閱讀 3349·2019-08-26 13:33
閱讀 2228·2019-08-26 13:33
