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