全棧認(rèn)知：應(yīng)用框架
【引子】 “探索嵌入式應(yīng)用框架（EAF）” 的那篇文字是應(yīng)用框架在嵌入式領(lǐng)域的具體示例，實(shí)際上，在服務(wù)器領(lǐng)域，應(yīng)用框架更是俯拾皆是。五一假期的時(shí)候， 開(kāi)始為全棧系列填坑，彌補(bǔ)空間維度的一個(gè)重要節(jié)點(diǎn)——應(yīng)用框架，根據(jù)日常累積，贅述成文。
軟件的應(yīng)用框架是軟件系統(tǒng)的一層抽象, 是提供了通用的軟件功能，可以通過(guò)用戶編寫(xiě)代碼有選擇地改變, 從而提供特定的軟件應(yīng)用。 應(yīng)用框架還提供了構(gòu)建和部署應(yīng)用程序的標(biāo)準(zhǔn)方式。 作為一個(gè)通用的、可重用的軟件環(huán)境, 它提供特定的功能, 作為軟件的一部分, 來(lái)促進(jìn)軟件應(yīng)用程序、產(chǎn)品和解決方案的開(kāi)發(fā)。 應(yīng)用框架可能包括輔助程序、編譯器、代碼庫(kù)、工具集和API , 匯集了所有不同的組件, 便于一個(gè)項(xiàng)目或系統(tǒng)的開(kāi)發(fā)。
框架與庫(kù)
對(duì)于研發(fā)效率以及產(chǎn)品質(zhì)量的提升而言，共享庫(kù)都具有重要的地位。共享庫(kù)高效地實(shí)現(xiàn)了代碼的重用，促進(jìn)了團(tuán)隊(duì)間產(chǎn)出的一致性。但是，開(kāi)發(fā)人員仍然需要選擇正確的庫(kù)，并清楚如何正確配置這些庫(kù)，并將這些庫(kù)正確地應(yīng)用在工程中。換句話說(shuō)，正確并高效地使用庫(kù)，并不是一件容易的事。而通過(guò)預(yù)先安裝和預(yù)先配置好的庫(kù)，應(yīng)用框架簡(jiǎn)化了開(kāi)發(fā)人員的工作量，并進(jìn)一步提高了一致性。當(dāng)然，沒(méi)有免費(fèi)的午餐，使用應(yīng)用框架的代價(jià)是某些靈活性的犧牲。
應(yīng)用框架不是單純的一堆庫(kù)集合，它一般都管理了整個(gè)應(yīng)用程序的生命周期。有質(zhì)量保障的應(yīng)用框架可以實(shí)現(xiàn)規(guī)模化開(kāi)發(fā)，例如，避免對(duì)每個(gè)應(yīng)用程序進(jìn)行深入的安全性代碼審查。另外，應(yīng)用框架所提供的跨團(tuán)隊(duì)乃至跨語(yǔ)言的一致性也是高級(jí)自動(dòng)化和智能系統(tǒng)的必要基礎(chǔ)。
應(yīng)用框架在許多方面具有共享庫(kù)的優(yōu)點(diǎn)，兩個(gè)主要的區(qū)別是: 控制反轉(zhuǎn)和可擴(kuò)展性。
控制反轉(zhuǎn)
在從零開(kāi)始構(gòu)建的應(yīng)用程序中，開(kāi)發(fā)人員來(lái)決定程序中正常的控制流程。在基于應(yīng)用框架的程序中，應(yīng)用框架自身將實(shí)現(xiàn)流程控制并調(diào)用開(kāi)發(fā)者的代碼，即反向控制或控制反轉(zhuǎn)。應(yīng)用框架的控制流程在所有應(yīng)用程序中都有良好的定義和標(biāo)準(zhǔn)。理想情況下，應(yīng)用程序只實(shí)現(xiàn)特定業(yè)務(wù)的邏輯，而應(yīng)用框架框架來(lái)可以處理所有其他細(xì)節(jié)。
可擴(kuò)展性
可擴(kuò)展性與控制反轉(zhuǎn)密切相關(guān)，調(diào)用的流程由應(yīng)用框架擁有，所以改變調(diào)用行為的唯一機(jī)制是通過(guò)應(yīng)用框架預(yù)留的擴(kuò)展模塊或接口。例如，服務(wù)器框架可能有某個(gè)擴(kuò)展接口，允許應(yīng)用程序在每次請(qǐng)求的前后運(yùn)行一些代碼。這還意味著，應(yīng)用框架的非擴(kuò)展部分是固定的，不能被應(yīng)用程序更改。
應(yīng)用框架的好處
除了類(lèi)似共享庫(kù)提供的功能之外，應(yīng)用框架還有許多好處，整個(gè)使用方如開(kāi)發(fā)人員，研發(fā)團(tuán)隊(duì)和公司乃至社區(qū)都會(huì)受益。
開(kāi)發(fā)人員
很明顯，開(kāi)發(fā)人員是應(yīng)用框架的直接受益者，使用應(yīng)用框架提高了生產(chǎn)力、簡(jiǎn)潔性和與最佳實(shí)踐的一致性。開(kāi)發(fā)人員可以充分利用應(yīng)用框架的內(nèi)置特性，從而減少了代碼的編寫(xiě)，而且使編寫(xiě)的代碼更簡(jiǎn)單。應(yīng)用框架通過(guò)提供合理的缺省值和缺省配置，消除了很多繁瑣耗時(shí)的開(kāi)發(fā)工作，為最佳實(shí)踐提供了一條簡(jiǎn)潔的路徑。
研發(fā)團(tuán)隊(duì)
除了提高開(kāi)發(fā)人員的生產(chǎn)力之外，應(yīng)用框架還有利于整個(gè)研發(fā)團(tuán)隊(duì)，使團(tuán)隊(duì)不用構(gòu)建冗余的基礎(chǔ)架構(gòu)，可以進(jìn)一步專(zhuān)注于產(chǎn)品的與眾不同。另一方面，研發(fā)團(tuán)隊(duì)同樣受益于應(yīng)用框架帶來(lái)的底層基礎(chǔ)設(shè)施的隔離。應(yīng)用框架提供的額外抽象意味著一些基礎(chǔ)設(shè)施完全可以由維護(hù)框架的人來(lái)處理。另外，應(yīng)用框架可以簡(jiǎn)化發(fā)布和評(píng)審流程，標(biāo)準(zhǔn)化也將使系統(tǒng)更容易管理。
公司與社區(qū)
在公司層面，通用的應(yīng)用框架可以減少開(kāi)發(fā)新應(yīng)用程序所需的時(shí)間，也增強(qiáng)了開(kāi)發(fā)人員的使用效率。如果一個(gè)公司擁有一個(gè)足夠大的開(kāi)發(fā)人員社區(qū)，那么投資高質(zhì)量的文檔和培訓(xùn)項(xiàng)目是值得的; 反過(guò)來(lái)，這也有助于吸引社區(qū)本身貢獻(xiàn)文檔和代碼。應(yīng)用框架的廣泛使用還意味著，對(duì)應(yīng)用框架的較小改進(jìn)就可以產(chǎn)生較大的影響。
隨著時(shí)間的推移，應(yīng)用框架可以對(duì)不斷變化的場(chǎng)景做出廣泛地應(yīng)對(duì)。例如，如果依賴(lài)于一致的微服務(wù)/RPC框架，并且?guī)捪鄬?duì)于 CPU 變得更加昂貴，那么，應(yīng)用框架默認(rèn)值可以根據(jù)成本權(quán)衡來(lái)調(diào)整參數(shù)。
框架的權(quán)衡
“欲知輕重而無(wú)以,予之以權(quán)衡”，雖然應(yīng)用框架具有很多好處，但同樣有利有弊，需要我們仔細(xì)權(quán)衡。
偏執(zhí)于框架會(huì)阻礙創(chuàng)新
通常，應(yīng)用框架必須選擇支持哪種類(lèi)型的技術(shù)，例如編程語(yǔ)言的選擇。支持所有的技術(shù)是不切實(shí)際的，如果應(yīng)用框架鼓勵(lì)使用某些技術(shù)或設(shè)計(jì)模式，針對(duì)這些技術(shù)或模式有明顯的優(yōu)勢(shì)。
應(yīng)用框架的相對(duì)固化可以極大地簡(jiǎn)化開(kāi)發(fā)人員的工作，使他們能夠直接開(kāi)發(fā)新系統(tǒng)而不被對(duì)系統(tǒng)中那些細(xì)微的決策細(xì)節(jié)所淹沒(méi)。對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)，接受相對(duì)固化的應(yīng)用框架允許他們專(zhuān)注于構(gòu)建業(yè)務(wù)系統(tǒng)。擁有一個(gè)共同的和一致的技術(shù)偏好也有利于整個(gè)公司，即使這個(gè)技術(shù)可能并不完美。
當(dāng)需要管理大量的應(yīng)用程序和研發(fā)團(tuán)隊(duì)的時(shí)候，某些產(chǎn)品的需求或團(tuán)隊(duì)擅長(zhǎng)的技術(shù)可能不太適合現(xiàn)有的應(yīng)用框架。應(yīng)用框架維護(hù)者決定了什么是最佳實(shí)踐，什么不是最佳實(shí)踐，判斷一個(gè)非常規(guī)用例是否“有效”，這可能會(huì)讓參與者感到不爽。
另一個(gè)重要的因素是，即使某些東西在今天是最佳實(shí)踐，但技術(shù)發(fā)展很快，肯定會(huì)存在應(yīng)用框架無(wú)法跟上創(chuàng)新步伐的風(fēng)險(xiǎn)。由于開(kāi)發(fā)者需要學(xué)習(xí)框架實(shí)現(xiàn)的細(xì)節(jié)或者依賴(lài)于框架維護(hù)者的幫助，因此如果嘗試替代基于應(yīng)用框架的應(yīng)用程序，成本可能會(huì)更高。
普遍性會(huì)導(dǎo)致不必要的抽象
許多應(yīng)用框架都有著公共控制平面，必須足夠通用才能支持絕大多數(shù)用例，這實(shí)際上意味著應(yīng)用框架擁有豐富的生命周期管理方式，以及任何應(yīng)用程序都需要的可擴(kuò)展性。這些需求必然會(huì)在應(yīng)用程序和底層庫(kù)之間添加一些中間層，這不但會(huì)增加CPU 的開(kāi)銷(xiāo)，還會(huì)增加認(rèn)知成本。對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)，更多的軟件分層層會(huì)使調(diào)試更加復(fù)雜。
應(yīng)用框架的另一個(gè)潛在缺點(diǎn)是，開(kāi)發(fā)人員必須學(xué)習(xí)這些框架。新技術(shù)的入門(mén)不再是“ hello world”，一個(gè)功能全面的應(yīng)用框架可能會(huì)使新技術(shù)的學(xué)習(xí)變得更復(fù)雜，而不是更好。
一般地，通過(guò)努力可以使每個(gè)應(yīng)用框架的核心盡可能簡(jiǎn)單且高效，并將其他功能作為可選模塊，還會(huì)提供支持應(yīng)用框架的工具，利用框架固有的結(jié)構(gòu)來(lái)簡(jiǎn)化調(diào)試。然而，最終，應(yīng)用框架的采用存在一個(gè)固有的成本，要確保采用應(yīng)用框架有足夠的好處并且學(xué)習(xí)成本是否合理。不同編程語(yǔ)言的應(yīng)用框架也可能有不同的配置方案，從而為開(kāi)發(fā)人員提供了一個(gè)決策和成本/收益場(chǎng)景。
應(yīng)用框架的重要特性
如前所述，控制反轉(zhuǎn)和可擴(kuò)展性是應(yīng)用框架的兩個(gè)基本特性，除此之外，還有一些其他的重要特性。
標(biāo)準(zhǔn)化的應(yīng)用程序生命周期
控制反轉(zhuǎn)的應(yīng)用框架意味著擁有并標(biāo)準(zhǔn)化了整個(gè)應(yīng)用程序的生命周期，但是這種結(jié)構(gòu)實(shí)際上能帶來(lái)什么好處呢？一個(gè)典型的用例是避免級(jí)聯(lián)故障。
眾所周知，級(jí)聯(lián)故障是系統(tǒng)中斷的常見(jiàn)原因。當(dāng)一個(gè)分布式系統(tǒng)的部分節(jié)點(diǎn)出現(xiàn)故障時(shí)，會(huì)發(fā)生級(jí)聯(lián)故障，也增加了其他部分出現(xiàn)故障的可能性。
一些應(yīng)用框架有一些內(nèi)置的防級(jí)聯(lián)故障的保護(hù)措施，其中最重要的原則是:
持續(xù)服務(wù)
如果服務(wù)器能夠成功地應(yīng)答請(qǐng)求，肯定是可以持續(xù)服務(wù)的。如果它只能夠成功地服務(wù)于某些類(lèi)型的請(qǐng)求，但不能服務(wù)于其他的請(qǐng)求，那么它就應(yīng)該繼續(xù)運(yùn)行并響應(yīng)能夠服務(wù)的請(qǐng)求。通俗的說(shuō)，就是服務(wù)降級(jí)。
快速啟動(dòng)
服務(wù)器應(yīng)該支持快速啟動(dòng)，因?yàn)楦斓膯?dòng)意味著更快的從崩潰中恢復(fù)。服務(wù)器應(yīng)該避免依賴(lài)外部系統(tǒng)的響應(yīng)來(lái)完成初始化。
在沒(méi)有應(yīng)用框架的情況下，自然會(huì)出現(xiàn)一種常見(jiàn)的反模式: 庫(kù)創(chuàng)建自己的 RPC 連接，然后等待連接就緒。隨著時(shí)間的推移，服務(wù)端所使用的庫(kù)會(huì)不斷增增加，最終可能會(huì)有數(shù)十個(gè)這樣的庫(kù)存在這樣的依賴(lài)，結(jié)果使服務(wù)器的初始化代碼變得越來(lái)越冗長(zhǎng)。當(dāng)一個(gè)相關(guān)的后端服務(wù)變慢或完全停止運(yùn)行時(shí)，這個(gè)問(wèn)題就會(huì)顯現(xiàn)出來(lái)——現(xiàn)在主服務(wù)器的啟動(dòng)被延遲了。如果啟動(dòng)被嚴(yán)重延遲，那么它在有開(kāi)始處理請(qǐng)求之前就可能會(huì)被干掉，最終導(dǎo)致級(jí)聯(lián)故障。
應(yīng)用框架提供了一個(gè)生產(chǎn)環(huán)境的正常基準(zhǔn)水平，如果只是將一堆互不相關(guān)的庫(kù)粘合在一起，那這個(gè)基準(zhǔn)水平將很難實(shí)現(xiàn)。
標(biāo)準(zhǔn)化的請(qǐng)求生命周期管理
雖然細(xì)節(jié)取決于應(yīng)用程序的類(lèi)型，但許多應(yīng)用框架還支持細(xì)粒度的生命周期管理。對(duì)于服務(wù)端的應(yīng)用框架而言，最重要的工作單元是請(qǐng)求。遵循類(lèi)似的控制反轉(zhuǎn)模型，請(qǐng)求的生命周期管理是將請(qǐng)求中不同方面的職責(zé)劃分為單獨(dú)的可擴(kuò)展代碼，從而使開(kāi)發(fā)人員可以專(zhuān)注于編寫(xiě)實(shí)際的業(yè)務(wù)邏輯。
具體地，對(duì)網(wǎng)絡(luò)安全而言，需要防范各種各樣的安全漏洞，例如 XSS (跨網(wǎng)站腳本)。XSS 漏洞通常是由于應(yīng)用程序返回的響應(yīng)數(shù)據(jù)沒(méi)有經(jīng)過(guò)足夠的過(guò)濾或轉(zhuǎn)義。傳統(tǒng)方法一般是添加缺失的轉(zhuǎn)義數(shù)據(jù)，并希望測(cè)試和代碼審查來(lái)防止出現(xiàn)類(lèi)似的問(wèn)題。
從根本上講，這種方法是行不通的，既然應(yīng)用程序接受了字符串或類(lèi)似的非結(jié)構(gòu)化/非類(lèi)型化數(shù)據(jù)，針對(duì)的底層API就很容易會(huì)出現(xiàn) XSS 之類(lèi)的錯(cuò)誤。例如，JavaServlet 為應(yīng)用程序提供了一個(gè)原始的 Writer，可以向它傳遞任意的字符。這個(gè)方法給開(kāi)發(fā)人員帶來(lái)了太多的負(fù)擔(dān)，而安全的應(yīng)用框架會(huì)具有上下文轉(zhuǎn)義感知的 HTML 模板系統(tǒng)以及抗 SQL注入的數(shù)據(jù)庫(kù)訪問(wèn)API。
一個(gè)良好的服務(wù)端應(yīng)用框架在請(qǐng)求的生命周期中補(bǔ)充了這些安全API的使用，從而使程序代碼不處理原始的字符串。相反，代碼返回的類(lèi)型保證了格式良好的對(duì)象構(gòu)造。這些響應(yīng)的轉(zhuǎn)換是響應(yīng)處理程序的職責(zé)，通常是應(yīng)用框架的內(nèi)置部分，改善了所有用戶的訪問(wèn)安全性。基于標(biāo)準(zhǔn)框架的服務(wù)端可以有效地跳過(guò)服務(wù)端啟動(dòng)所需的許多安全審查，因?yàn)閼?yīng)用框架本身可以保證某些行為的安全性。
當(dāng)然，結(jié)構(gòu)化和可擴(kuò)展的請(qǐng)求生命周期管理遠(yuǎn)遠(yuǎn)超出了將業(yè)務(wù)邏輯與響應(yīng)序列化分離的范疇。最基本的好處是，它使每個(gè)組件都很小，并且易于演進(jìn)，這有助于長(zhǎng)期的代碼健康。應(yīng)用程序可以在不觸及每個(gè)具體動(dòng)作的前提下引入自己的特性，在某些情況下，這些特性是特定于領(lǐng)域的，但可能最終可以上移到應(yīng)用框架的自身實(shí)現(xiàn)。
公共控制層面
公共控制層面包括了所有非特定應(yīng)用的輸入和輸出，例如操作控制、監(jiān)控、日志記錄和配置。基于公共控制層面，服務(wù)端之間的一致性使故障排除更加容易，跨服務(wù)的公共控制面也使自動(dòng)化的共享成為可能。例如，如果所有服務(wù)端都以標(biāo)準(zhǔn)方式導(dǎo)出錯(cuò)誤，那么修改發(fā)布流水線以執(zhí)行自動(dòng)銷(xiāo)毀就成為可能: 可以先小流量發(fā)布一個(gè)新文件，然后再在執(zhí)行全量發(fā)布之前查找錯(cuò)誤點(diǎn)。
應(yīng)用框架實(shí)現(xiàn)了跨越應(yīng)用控制層面的一致性。雖然一般來(lái)說(shuō)，只有少數(shù)人關(guān)心控制層面的精確組成，但擁有一個(gè)統(tǒng)一方式對(duì)公司來(lái)說(shuō)具有巨大的價(jià)值。一致性意味著可以輕松地實(shí)現(xiàn)文件共享和自動(dòng)化擴(kuò)展。通過(guò)簡(jiǎn)化與周?chē)鷳B(tài)系統(tǒng)的集成，可以獲得標(biāo)準(zhǔn)化使用的多重好處。
實(shí)現(xiàn)公共控制層面的一個(gè)挑戰(zhàn)是，應(yīng)用框架的維護(hù)者通常會(huì)發(fā)現(xiàn)編程語(yǔ)言庫(kù)之間的不一致性。例如，大多數(shù)編程語(yǔ)言都有一個(gè)命令行參數(shù)的概念，從積極的一面來(lái)看，語(yǔ)法在一定程度上在各種語(yǔ)言之間是兼容的。如今，庫(kù)的所有者更加意識(shí)到跨語(yǔ)言一致性的價(jià)值，以及考慮這種一致性的必要性。
模塊化
盡管大多數(shù)開(kāi)發(fā)人員使用同一個(gè)的代碼倉(cāng)庫(kù)，但是團(tuán)隊(duì)之間的工程實(shí)踐仍然存在較大差異。技術(shù)框架的選擇通常取決于項(xiàng)目的技術(shù)領(lǐng)導(dǎo)，而缺乏有自上而下的授權(quán)。可以理解的是，人們傾向于選擇自己以前有經(jīng)驗(yàn)的技術(shù)。因此，為了讓一項(xiàng)新技術(shù)獲得廣泛的應(yīng)用，它必須具有明顯的價(jià)值或者較低的進(jìn)入門(mén)檻; 通常，它必須兩者兼而有之。
核心以及請(qǐng)求的生命周期管理是應(yīng)用框架的核心特性，所有其他功能都可以捆綁到可選的獨(dú)立模塊中，開(kāi)發(fā)人員可以選擇將哪些模塊添加到他們的服務(wù)中。
模塊的獨(dú)立性還允許將特定于應(yīng)用程序的模塊輕松替換為標(biāo)準(zhǔn)框架的模塊。因?yàn)闃?biāo)準(zhǔn)框架模塊與特定于應(yīng)用的模塊使用了相同的可擴(kuò)展API，所以將有用的功能上移到應(yīng)用框架通常只是移動(dòng)代碼的位置而已。這樣，應(yīng)用框架會(huì)成為不斷增長(zhǎng)的最佳實(shí)踐集合， 使許多開(kāi)發(fā)人員免于執(zhí)行復(fù)雜或昂貴的遷移，對(duì)于許多研發(fā)團(tuán)隊(duì)來(lái)說(shuō)，這是應(yīng)用框架最引人注目的好處之一。
應(yīng)用框架維護(hù)者的一個(gè)角色是確保模塊之間的正確協(xié)作，選擇默認(rèn)的模塊列表，或者提供關(guān)于在不同情況下應(yīng)該使用哪些模塊的建議和約束。盡管開(kāi)發(fā)人員傾向于使用細(xì)粒度模塊來(lái)實(shí)現(xiàn)靈活性，但框架維護(hù)者很難確保所有組合都能很好地協(xié)同工作。
應(yīng)用框架的進(jìn)一步抽象——例如 微服務(wù)的平臺(tái)化
應(yīng)用框架的廣泛使用所提供的標(biāo)準(zhǔn)化為更高級(jí)別的工具化和自動(dòng)化帶來(lái)了機(jī)會(huì)，例如，微服務(wù)的平臺(tái)化。
微服務(wù)之前的單體服務(wù)
過(guò)去，無(wú)論涉及怎樣的服務(wù)發(fā)布，除了編碼之外，都要涉及集成測(cè)試、啟動(dòng)安全和隱私評(píng)審、 上線部署、執(zhí)行發(fā)布、收集和保存日志、AB實(shí)驗(yàn)以及調(diào)試和解決故障等等，這些都是所有服務(wù)必須完成的過(guò)程。因此，很多時(shí)候不是部署新的服務(wù)器，而是向現(xiàn)有服務(wù)中添加代碼。這樣。團(tuán)隊(duì)可以專(zhuān)注于他們的業(yè)務(wù)邏輯，并“免費(fèi)”獲得可用的工程環(huán)境。當(dāng)然，一旦有很多團(tuán)隊(duì)采用這種方法，目標(biāo)服務(wù)器就會(huì)不斷增長(zhǎng)，從而變成巨大的且難以維護(hù)的單體服務(wù)。
單體服務(wù)有許多負(fù)面影響。在開(kāi)發(fā)人員的生產(chǎn)力方面，必須處理緩慢的構(gòu)建、緩慢的服務(wù)器啟動(dòng)，以及在嘗試提交更改時(shí)的沙盒測(cè)試很可能中斷的問(wèn)題。
當(dāng)發(fā)布版本的時(shí)候，按計(jì)劃整體發(fā)布是很有挑戰(zhàn)的。隨著單體服務(wù)的增長(zhǎng)，有貢獻(xiàn)的開(kāi)發(fā)人員的數(shù)量也在增長(zhǎng)，這自然會(huì)導(dǎo)致更多的異常阻塞。延遲發(fā)布可能會(huì)使實(shí)現(xiàn)下一個(gè)發(fā)布變得更加困難，最終會(huì)形成一個(gè)惡性循環(huán)。
在生產(chǎn)環(huán)境中，單體服務(wù)在表面上毫無(wú)關(guān)聯(lián)的服務(wù)之間構(gòu)建了一個(gè)危險(xiǎn)的命運(yùn)共享，同時(shí)也增加了意外交互導(dǎo)致bug的可能性。巨型的單體服務(wù)使得資源供應(yīng)更加困難，獨(dú)立地?cái)U(kuò)展這類(lèi)服務(wù)幾乎是不可能的。
遠(yuǎn)離面向服務(wù)器的世界
盡管大家都清楚單體服務(wù)是不可持續(xù)的，但是沒(méi)有好的替代方案。開(kāi)發(fā)人員應(yīng)該專(zhuān)注于他們特定于應(yīng)用服務(wù)的業(yè)務(wù)邏輯，并且其他所有東西都應(yīng)該盡可能地自動(dòng)化，從這個(gè)目標(biāo)出發(fā)，應(yīng)用框架的需求最終變得清晰起來(lái):
開(kāi)發(fā)人員應(yīng)該聲明和實(shí)現(xiàn)服務(wù)的API，而 協(xié)調(diào)API的運(yùn)行方式是應(yīng)用框架平臺(tái)的角色。
自動(dòng)化所需的所有元數(shù)據(jù)，包括生產(chǎn)配置，應(yīng)與服務(wù)代碼一起聲明。
服務(wù)之間的資源和依賴(lài)關(guān)系應(yīng)該是明確的且可聲明的。理想情況下，我們應(yīng)該能夠通過(guò)查看服務(wù)全域的元數(shù)據(jù)來(lái)可視化整個(gè)生產(chǎn)拓?fù)洹７?wù)應(yīng)該相互隔離，以便任意服務(wù)都可以共同組裝到服務(wù)器中。而在其他要求中，這意味著要避免全局狀態(tài)和副作用。
當(dāng)這些要求得到滿足時(shí)，幾乎所有以前的手工過(guò)程都可以自動(dòng)化。例如，在運(yùn)行集成測(cè)試時(shí)，測(cè)試基礎(chǔ)結(jié)構(gòu)可以是元數(shù)據(jù)連接服務(wù)依賴(lài)關(guān)系圖的一部分。一個(gè)使用這些原則的應(yīng)用框架平臺(tái)，可以被其他團(tuán)隊(duì)有機(jī)地采用，并最終分離成一個(gè)單獨(dú)的項(xiàng)目。
如今，基于微服務(wù)的應(yīng)用框架平臺(tái)幾乎成為了新服務(wù)開(kāi)發(fā)的行業(yè)標(biāo)準(zhǔn)，一個(gè)重要原因是它同時(shí)吸引了小型團(tuán)隊(duì)和大型組織。由于高水平的自動(dòng)化，小型團(tuán)隊(duì)現(xiàn)在可以輕松地在幾天內(nèi)提供高質(zhì)量的生產(chǎn)服務(wù)，而在此之前，最佳實(shí)踐可能需要幾個(gè)月的時(shí)間。對(duì)于大型組織來(lái)說(shuō)，團(tuán)隊(duì)間的一致性降低了支持成本，而應(yīng)用框架平臺(tái)意味著特定于組織的基礎(chǔ)設(shè)施團(tuán)隊(duì)通常不再是必要的。
轉(zhuǎn)向微服務(wù)的另一個(gè)好處是鼓勵(lì)開(kāi)發(fā)人員更多地考慮服務(wù)之間的合理分工，這將導(dǎo)致更合理的系統(tǒng)架構(gòu)。使用諸如 gRPC 和分布式緩存之類(lèi)的技術(shù)作為不同系統(tǒng)之間的邊界，迫使開(kāi)發(fā)人員以一種面向不一確定性的方式來(lái)考慮API，而不只是考慮在同一進(jìn)程中使用函數(shù)調(diào)用的情況。RPC 系統(tǒng)也與語(yǔ)言無(wú)關(guān)，因此每個(gè)微服務(wù)的擁有者可以獨(dú)立決定使用哪種語(yǔ)言。
剩下的挑戰(zhàn)，就是提供更高級(jí)別的工具來(lái)管理日益增多的微服務(wù)。例如，以前編寫(xiě)的監(jiān)控軟件能假定只有相對(duì)少量的目標(biāo)對(duì)象，這就需要一個(gè)新的用戶界面來(lái)容納更多監(jiān)控對(duì)象。
微服務(wù)與應(yīng)用框架的關(guān)系
應(yīng)用框架是微服務(wù)平臺(tái)的重要組成部分，原因如下:
應(yīng)用框架生命周期中固有的控制反轉(zhuǎn)/服務(wù)模式自然而然地適用于這種模式，即應(yīng)用程序開(kāi)發(fā)人員只將他們的服務(wù)實(shí)現(xiàn)交給平臺(tái)。
許多平臺(tái)特性都需要通用控制服務(wù)(跨服務(wù)器和語(yǔ)言) ，包括發(fā)布管理、監(jiān)視和日志記錄。
模塊化意味著平臺(tái)和應(yīng)用程序代碼都可以提供獨(dú)立的模塊，當(dāng)這些模塊組合在一起時(shí)，可以以一種健全的方式構(gòu)成一個(gè)完整的服務(wù)。
如前所述，應(yīng)用框架可以提供更高級(jí)別的封裝，從而簡(jiǎn)化了應(yīng)用程序的編寫(xiě)，并提供了與底層庫(kù)的隔離。與此類(lèi)似，面向微服務(wù)的應(yīng)用框架平臺(tái)不僅僅封裝了代碼，還封裝了如生產(chǎn)配置之類(lèi)的其他組件。這允許更高級(jí)別的簡(jiǎn)化以及故障域間的相互隔離。例如，維護(hù)人員可以(如果必要的話)自動(dòng)應(yīng)用緊急代碼修正（回滾）或配置更改，重新構(gòu)建所有受影響的文件，并以統(tǒng)一的方式將它們推向生產(chǎn)環(huán)境。
然而，使用微服務(wù)的應(yīng)用框架平臺(tái)確實(shí)存在一些挑戰(zhàn)。其中最大的一個(gè)問(wèn)題是，強(qiáng)制約束使微服務(wù)平臺(tái)正常運(yùn)行所需的所有不變量可能是繁重的，甚至可能影響應(yīng)用程序的編碼方式。舉個(gè)例子，Java 服務(wù)共享的某些線程池。所有服務(wù)必須彼此隔離的要求意味著不能允許有阻塞請(qǐng)求的線程模型。出于這個(gè)原因，服務(wù)被要求只能使用異步，然而這種解決方案并不能讓所有的團(tuán)隊(duì)都滿意。
另一個(gè)挑戰(zhàn)是，在微服務(wù)之間添加更多的節(jié)點(diǎn)可能會(huì)增加總體請(qǐng)求的延遲。在某些情況下，這種延遲可以通過(guò)體系結(jié)構(gòu)的改進(jìn)來(lái)減輕。對(duì)于微服務(wù)的應(yīng)用框架平臺(tái)，要確保恰好位于同一服務(wù)端上的服務(wù)之間的請(qǐng)求使用優(yōu)化的進(jìn)程內(nèi)傳輸。
小結(jié)
雖然，應(yīng)用框架是一個(gè)強(qiáng)大的工具，但也有一些缺點(diǎn)，并不是所有團(tuán)隊(duì)都愿意維護(hù)應(yīng)用框架的標(biāo)準(zhǔn)化和定義良好的行為方式，同時(shí)不能過(guò)度規(guī)范化。然而，當(dāng)應(yīng)用框架達(dá)到合理的平衡時(shí)，可以大幅提高研發(fā)團(tuán)隊(duì)的生產(chǎn)力。
應(yīng)用框架所提供的一致性對(duì)于研發(fā)團(tuán)隊(duì)來(lái)說(shuō)是一個(gè)福音，為構(gòu)建更高層次的抽象提供了基礎(chǔ)，例如微服務(wù)的應(yīng)用框架平臺(tái)化，它為系統(tǒng)架構(gòu)和自動(dòng)化開(kāi)啟了新的機(jī)遇。
【關(guān)聯(lián)閱讀】