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