1.?可演進(jìn)的API
1.1.?隨著需求的變化，你需要改變你的API，即代碼之間的共享接口
1.2.?改變API很容易，但很難做到正確
1.3.?保持API小巧
1.3.1.?小巧的API更易于理解和演進(jìn)
1.3.2.?只添加即刻需要的API方法或字段
1.3.3.?帶有許多字段的API方法應(yīng)該有合理的默認(rèn)值
1.3.3.1.?開發(fā)人員可以只專注于和自己相關(guān)的字段，因?yàn)樗鼈儠?huì)繼承其他字段的默認(rèn)值
1.3.3.2.?默認(rèn)值可使大型API在感覺上很小巧
1.4.?公開定義良好的服務(wù)端API
1.4.1.?切記使用標(biāo)準(zhǔn)工具來定義服務(wù)端API
1.4.1.1.?OpenAPI通常用于RESTful服務(wù)
1.4.1.2.?non-REST服務(wù)則使用Protocol Buffers、Thrift或類似的接口定義語言(interface definition language，IDL)
1.4.1.3.?接口定義工具自帶代碼生成器，可以將服務(wù)的定義轉(zhuǎn)換為客戶端和服務(wù)端代碼
1.4.1.4.?文檔也可以被生成，測試工具可以使用IDL來生成stub數(shù)據(jù)和模擬數(shù)據(jù)
1.5.?保持API變更的兼容性
1.5.1.?向前兼容
1.5.1.1.?向前兼容的變更允許客戶端在調(diào)用舊版的服務(wù)時(shí)使用新版的API
1.5.1.2.?一個(gè)正在運(yùn)行1.0版API的網(wǎng)絡(luò)服務(wù)，但可以接收來自使用1.1版API的客戶端的調(diào)用，這就是向前兼容
1.5.2.?向后兼容
1.5.2.1.?向后兼容的變更：新版本的庫或服務(wù)不需要改變舊的客戶端代碼
1.5.2.2.?如果針對1.0版API開發(fā)的代碼在使用1.1版時(shí)能繼續(xù)編譯和運(yùn)行，這種變更就被稱為向后兼容
1.6.?API版本化
1.6.1.?隨著API的不斷演進(jìn)，你將需要決定如何處理多個(gè)版本的兼容性
1.6.2.?完全向后兼容和向前兼容的變更意味著API的所有的歷史版本和未來版本都可以相互操作
1.6.3.?你會(huì)想變更你的API，使之與舊的客戶端不兼容
1.6.3.1.?當(dāng)客戶端代碼難以變更時(shí)，API的版本管理最有價(jià)值
1.6.4.?版本化你的API意味著你在做出改變時(shí)將引入一個(gè)新的版本
1.6.4.1.?API版本化自有其代價(jià)
1.6.4.2.?舊的主版本服務(wù)需要被維護(hù)，修復(fù)的bug也需要回傳到以前的版本
1.6.5.?API版本通常由API網(wǎng)關(guān)或服務(wù)網(wǎng)格來管理
1.6.5.1.?管理版本所采用的方法要?jiǎng)?wù)實(shí)
1.6.6.?將文檔與你的API一起保持版本化
2.?可持續(xù)的數(shù)據(jù)管理
2.1.?API比持久化數(shù)據(jù)存續(xù)的時(shí)間更短
2.1.1.?一旦客戶端和服務(wù)端API都升級(jí)了，就意味著工作完成了
2.2.?隔離數(shù)據(jù)庫和使用明確的schema將使數(shù)據(jù)演進(jìn)更易于管理
2.3.?數(shù)據(jù)庫隔離
2.3.1.?共享的數(shù)據(jù)庫很難演進(jìn)，并且會(huì)導(dǎo)致喪失自主性
2.3.1.1.?圖
文章來源：http://www.zghlxwxcb.cn/news/detail-760347.html
2.3.2.?擁有共享數(shù)據(jù)庫的應(yīng)用程序可以發(fā)展到直接依賴對方的數(shù)據(jù)，應(yīng)用程序應(yīng)該作為它們所使用的底層數(shù)據(jù)的控制點(diǎn)
2.3.3.?隔離的數(shù)據(jù)庫只有一個(gè)讀取者和寫入者
2.3.3.1.?其他所有流量都通過遠(yuǎn)程過程調(diào)用
2.3.3.2.?圖
文章來源地址http://www.zghlxwxcb.cn/news/detail-760347.html
2.3.4.?隔離數(shù)據(jù)庫為你提供了共享數(shù)據(jù)庫所不具備的靈活性和隔離性
2.4.?使用schema
2.4.1.?僵化的預(yù)定義數(shù)據(jù)列和類型，以及它們演進(jìn)的重量級(jí)過程，會(huì)導(dǎo)致流行的無模式(schemaless)數(shù)據(jù)管理的出現(xiàn)
2.4.2.?無模式并不意味著“沒有模式”（數(shù)據(jù)將無法使用）
2.4.3.?不要將無模式的數(shù)據(jù)隱藏在已經(jīng)模式化的數(shù)據(jù)中
2.4.3.1.?隱藏?zé)o模式的數(shù)據(jù)是“自取滅亡”，你獲得了顯式schema的所有痛苦，卻沒有任何收益
2.4.4.?無模式數(shù)據(jù)有一種隱含的模式，可以在讀取時(shí)被提供或推斷出來
2.4.5.?采用無模式的方法會(huì)產(chǎn)生明顯的數(shù)據(jù)完整性和復(fù)雜性問題
2.4.6.?強(qiáng)類型的面向schema的方法降低了應(yīng)用程序的隱蔽性，因此也降低了其復(fù)雜性
2.4.7.?為你的數(shù)據(jù)定義明確的schema將使你的應(yīng)用程序保持穩(wěn)定，并使你的數(shù)據(jù)可用
2.4.7.1.?明確的schema會(huì)讓你在編寫數(shù)據(jù)時(shí)可以對其進(jìn)行合理性檢查
2.4.7.2.?使用顯式schema解析數(shù)據(jù)通常會(huì)更快捷
2.4.7.3.?架構(gòu)還可以幫助你檢測到前后不兼容的變化
2.4.8.?數(shù)據(jù)有時(shí)被描述為“一次寫入，多次讀取”，使用schema可以使讀取更容易
2.4.9.?schema自動(dòng)化遷移
2.4.9.1.?改變一個(gè)數(shù)據(jù)庫的schema是危險(xiǎn)的
2.4.9.2.?可以管理數(shù)據(jù)庫遷移的工具
2.4.9.2.1.?Liquibase
2.4.9.2.2.?Flyway
2.4.9.2.3.?Alembic
2.4.9.2.4.?GitHub的gh-ost
2.4.9.2.5.?Percona的pt-online-schema-change
2.4.9.2.6.?Skeema
2.4.9.2.7.?Square的Shift
2.4.9.3.?大多數(shù)遷移工具都支持回滾，也就是可以撤銷遷移產(chǎn)生的變化
2.4.10.?保持schema的兼容性
2.4.10.1.?寫入磁盤的數(shù)據(jù)也有和API一樣的兼容性問題
2.4.10.2.?變更數(shù)據(jù)捕獲(change data capture，CDC)是一種基于事件的架構(gòu)，將插入、更新和刪除操作轉(zhuǎn)換為下游使用者的消息
2.4.10.3.?數(shù)據(jù)倉庫管道和下游用戶必須受到保護(hù)，以免遭受schema變更帶來的不良影響
2.4.10.4.?兼容性檢查應(yīng)該盡早地進(jìn)行，最好是在提交代碼時(shí)通過檢查數(shù)據(jù)庫DDL語句來進(jìn)行
2.4.10.5.?獨(dú)立的數(shù)據(jù)產(chǎn)品，可能只是數(shù)據(jù)庫視圖，允許團(tuán)隊(duì)與數(shù)據(jù)的消費(fèi)者保持兼容，而不必凍結(jié)其內(nèi)部的數(shù)據(jù)庫schema
到了這里，關(guān)于讀程序員的README筆記17_構(gòu)建可演進(jìn)的架構(gòu)（下）的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
