2019架構(gòu)師-年10月微軟宣布開源使用二十余年庫

CONTENTS|微軟宣布開源使用二十余年的C++標(biāo)準(zhǔn)庫理論派|亞馬遜CTO的“中臺論推薦文章|京東技術(shù)中臺的Flutter實踐如何將代碼部署時間減少95%？我在Uber運營大型分布式系統(tǒng)三年經(jīng)驗談Dropbox如何用四年完成400萬行Python代碼檢觀點|DockervsKubernetes，容器生態(tài)圈現(xiàn)2019年

提供反饋商務(wù)合作內(nèi)容合作 卷首 作者，PerceptIn創(chuàng)始人，著有《第一本無人駕駛技術(shù)書我們已經(jīng)拉開了全自動無人駕駛的序幕，在幕布之后的未來將如何？讓我們先回顧一下硅谷的發(fā)展歷史，再以此展望無人駕駛的未來?，F(xiàn)代始于20世紀(jì)60年代，仙童電子和n通過硅晶體微處理器技術(shù)的創(chuàng)新開創(chuàng)了的新時代，這也是硅谷的。微處理器技術(shù)極大地提高了工業(yè)化生產(chǎn)力，推進了現(xiàn)代工業(yè)的發(fā)展。20世紀(jì)80年代隨著XeoxAo、AppeLa及 indows等軟件系統(tǒng)的圖形界面被廣泛應(yīng)用，個人電腦的概念出現(xiàn)并開始普及，現(xiàn)代以此為基礎(chǔ)普惠眾人。21世紀(jì)初，在個人電腦逐步普及并被大規(guī)模應(yīng)用的背景下，谷歌的出現(xiàn)通過互聯(lián)網(wǎng)和搜索引擎的方式將人與浩瀚如星海的信息互聯(lián)起來，至此，現(xiàn)代發(fā)展到了第三階段。始于2004年的通過革新的社交網(wǎng)絡(luò)模式將現(xiàn)代推進到了第四階段。至此，人類的交往互聯(lián)方式從線下擴展到了線上，人類社會在網(wǎng)上有了初始的遷移并逐步地成熟完善。隨著互聯(lián)網(wǎng)人口規(guī)模的膨脹，信息技術(shù)發(fā)展進入第五階段Abnb與Uber等公司通過共享經(jīng)濟的思維把類社會的經(jīng)濟模式直接推廣到了互聯(lián)網(wǎng)社會，利用互聯(lián)網(wǎng)+移動設(shè)備等直接連接不同用戶的經(jīng)濟行為，取得了大范圍的成功。每一階段的發(fā)展及其隨后驅(qū)動的革新，都極大地改變了人類對信息的需求和獲取方式。尤其對后幾個階段而言，互聯(lián)網(wǎng)是一個基礎(chǔ)性條件，大多數(shù)的服務(wù)是通過互聯(lián)網(wǎng)傳達給終端用戶的?，F(xiàn)在，我們走到了發(fā)展的第六階3架構(gòu)師2019架構(gòu)師2019年10月機器人開始作為服務(wù)的承載體出現(xiàn)，其中的一個具體事例就是無人駕駛的產(chǎn)品化。無人駕駛的場景特別復(fù)雜，技術(shù)特別大，它因此被稱為AI技而AI技術(shù)只是無人駕駛眾多中的一部分。而無人駕駛是一個系統(tǒng)工程，需要把眾多的單點技術(shù)進行有效的整合，能否開發(fā)出一款好的無人駕駛產(chǎn)品取決于一個團隊的全棧式工程能力與系統(tǒng)型整合能力，因此對整個無人駕駛架構(gòu)的全面了解至關(guān)重要。4微軟宣布開源使用二十余C++標(biāo)準(zhǔn)作者：StephanT.Lavavej譯者20192019916日，微軟C++團隊博CppCon 可稱為STL）。據(jù)了解，MSVCC++標(biāo)準(zhǔn)庫開源之后，新的庫地址為 /STL，其中包含了所有的產(chǎn)品源代碼、新的CMake構(gòu)建系統(tǒng)和信息的自述文件。微軟C++團隊正在努力將其遷移到中，目前雖然可以克隆和構(gòu)建代碼，但是在查看拉取請求之前，微軟C++團隊在博客中，也回答了幾個大家都很關(guān)心的問題，微軟C++團隊：選擇開源主要是因為以下的原因：開源之后，在中使用STL允許用戶我們的開發(fā)，并可嘗試使用更改同時還可以通過來幫助改進我們的拉取請求；隨著C++標(biāo)準(zhǔn)化的加受開源貢獻的主要功能是非常重要的，例如C++20的計時和格式庫。另外，我們也希望能夠通過主要功能的實現(xiàn)來回饋C++社區(qū)，例如C++13STL使用的是什么開源？是否會直接影響VisualStudio的客戶？微軟C++團隊：MSVCSTL的開源為ApacheLicensev2.0LLVMExceptions，是由Clang/LLVM/libc++項目創(chuàng)建的。之所以會選擇這個較為寬松的開源，是因為擁有l(wèi)ibc++相同的能夠使得庫之間共享代碼變得更容易。需要注意的是，MSVCSTL并沒有與libc++合并，它們?nèi)匀皇侵С志哂胁煌瑪?shù)據(jù)結(jié)構(gòu)表示的不同平臺的不同庫，不過，如果libc++的者有從MSVC的STL中獲取必?fù)?dān)心。對于MSVCSTL的客戶來說，可能會擔(dān)心開源的問題，微軟在開源中明確，客戶使用MSVCSTL編譯自己源代碼生成目標(biāo)代品發(fā)送給最終用戶時，無需提供歸屬信息。這也是我們選擇這個開源（附加說明：MSVC的STL中包含來自Boost的源代碼，Math和Ryu可在BoostSoftwareLicensev1.0下使用。這是另一個開源，也包含對象代碼的顯式異常。我們派生的源代碼是在ApacheLicensev2.0LLVMExceptions發(fā)布的。）是否有打算開源MSVC工具集中的其它工具嗎微軟C++團隊：目前沒有這樣的計劃，之所以開源STL，是因為它與其他MSVC庫和編譯器不同。具體而言，STL是由C++標(biāo)準(zhǔn)化快速發(fā)展和設(shè)計的，與其他MSVC庫不同，由設(shè)計是開源的一個優(yōu)勢，這意味著我們不需要花費任何時間和精力進行功能設(shè)計，另外，實施和策略受到約束，因此更容易。STL與編譯器不同，相對容易貢獻，并且松耦合，也許，未來我們可能會開源STL支持庫在開源過程中遇到了哪些難題微軟C++團隊：遇到了一個小問題，因為我們花費了一些時間來檢測構(gòu)建系統(tǒng)、測試基礎(chǔ)架構(gòu)和問題，因為關(guān)于C++20庫功能的工作有些延遲了。不過，我們剛剛完成了所有C++17庫的功能，所以C++20庫應(yīng)該不會是問題，我們能夠更有效地處理STL，使得其更快地達到C20的完整性作者WernerVogels譯者核子可作作者WernerVogels總結(jié)AWS這二十多年來，如何通的CTO，他撰寫了一篇文應(yīng)用程序架構(gòu)、調(diào)整企業(yè)織架構(gòu)等方式，讓構(gòu)建現(xiàn)代應(yīng)用程序的客戶“將時間花在定義務(wù)邏輯上，擴展系統(tǒng)以輕松滿足期客戶需求，提高敏捷性，同時調(diào)整為小團隊并“賦予他們對應(yīng)用程序內(nèi)特定部分的操作權(quán)限”，不謀而合了。也可謂是亞馬遜的“中臺論”，雖然他們并沒有使用個詞創(chuàng)新一直是亞馬遜公司DNA中的重要組成部分，但大約20年之前， 那個時候，亞馬遜所服務(wù)的客戶數(shù)量遠不及當(dāng)下。盡管如此，我們 算為客戶提供新的功能或者產(chǎn)品例如流時，我們就必須在專為了從根本上解決這一難題，我們通過《分布式計算》建立起新的藍圖。這是一份描述新架構(gòu)的文檔。通過這份，我們開將自身應(yīng)用程序通過眾多被稱為“服務(wù)”的小型基本單元加以重組，從而大幅提升對亞馬遜整體業(yè)務(wù)的擴展能力。但是，應(yīng)用程序架構(gòu)只是故事的前一半。至于后一半……當(dāng)時是1998年，亞馬遜的各個開發(fā)團隊都在使用相同的應(yīng)用程序，因此每。為了支持這種新型架構(gòu)，我們分解了功能層級結(jié)構(gòu)，并將企業(yè)組織重新編排為小型自治團隊 小到每次點餐只需要兩份披薩 這“雙披薩團隊”委派到不同的特定產(chǎn)品、服務(wù)或者功能集上，賦予他們對應(yīng)用程序內(nèi)特定部分的操作權(quán)限這使得我們的開發(fā)成為產(chǎn)品所有者，并能夠根據(jù)自己的決策迅速對個別產(chǎn)品產(chǎn)生影響。。 這就是2006年誕生的AWS。而我們，如今仍在堅持雙披薩團隊這一基本建制元或者說“微服務(wù)”，而且除此之外，現(xiàn)代應(yīng)用程序的最佳實踐還要求在改變設(shè)計與構(gòu)建技術(shù)之余，重新考慮其管理方式適合自身的順序采用以下五大元素：微服務(wù)、數(shù)據(jù)庫、自動軟件發(fā)布架構(gòu)模式：微服像亞馬遜這樣的大多數(shù)企業(yè)最初都是以整體式應(yīng)用程序作為業(yè)務(wù)基果應(yīng)用程序中的某個進程遭遇需求，我們只能擴展整體架構(gòu)才能實現(xiàn)單個進程的擴容。服務(wù)形式運行。服務(wù)將專為業(yè)務(wù)功能而構(gòu)建，例如購物車，而且每項隨著組織由整體式架構(gòu)逐步轉(zhuǎn)向微服務(wù)架構(gòu)，很多開發(fā)也希望通過流水線管理各項服務(wù)中的依賴關(guān)系這就要求我們創(chuàng)造出新的方法以大家也可以使用容器或者WSLabda函數(shù)。容器是目前最受歡迎的代碼打包選項，同時也是實現(xiàn)遺留應(yīng)用程序現(xiàn)代化的最佳工具之一。容器技術(shù)，為我們帶來出色的應(yīng)用程序可移植性與設(shè)置靈活性。而利用Labd，大家則能夠更輕松地獲取所需功能利用代碼編寫出業(yè)務(wù)邏輯即可。微服務(wù)架構(gòu)的另一大需求，在于須為之建立一種服務(wù)間的相通信方式。目前大部分應(yīng)用程序都繼續(xù)沿用API連接，但也有一些選擇數(shù)據(jù)管理：數(shù)據(jù)以最適合自身需求的不同數(shù)據(jù)庫類型。圖數(shù)據(jù)庫，例如AmazonNeptune。或者，如果您的應(yīng)用程序需要實時數(shù)據(jù)，也可以選擇AmazonElastiCache等內(nèi)存內(nèi)數(shù)據(jù)庫，其常用于游戲以及物聯(lián)網(wǎng)應(yīng)用場景。一般來軟件交付：自動發(fā)布流水雖然這種新方式消除了更新的開發(fā)與交付等協(xié)調(diào)性，但同時也給我們的解決方案采取雙管齊下的方式：標(biāo)準(zhǔn)化加上自動化。首先，我資源的建模與配置提供標(biāo)準(zhǔn)。這些“基礎(chǔ)設(shè)施即代碼”模板能夠幫助我們的不再依賴于手動過程。在亞馬遜，這種作法確保了各個團隊都能夠根據(jù)我們的要求實現(xiàn)對流程與部署的配置第二點，我們開始利用自動化技術(shù)將手動流程從軟件交付流水線中剔除出去。在自動化發(fā)布流水線的幫助下（包括持續(xù)集成與持續(xù)部署，簡稱CD），我們得以快速測試并發(fā)布大量代碼，同時最大限度減少錯誤機率。通過CI，我們的團隊會定期將代碼變更整合至同一套庫內(nèi)。而后，我們會對其運行自動構(gòu)建與測試，以確保能夠盡早發(fā)現(xiàn)問題。而利用D，我們的團隊每天可以多次提交變更，且無需任何人為干預(yù)即可將成果投入生產(chǎn)。起初，我們發(fā)現(xiàn)去掉人為干預(yù)只會帶來相當(dāng)糟糕的部署。但是，運營模式：盡可能采用無服務(wù)器模一項服務(wù)背后都對應(yīng)著一套數(shù)據(jù)庫外加一支負(fù)責(zé)不斷發(fā)布新功能的團這些活動部件可以分為以下兩類作為企業(yè)“獨門絕技”的活動組件，負(fù)責(zé)保障業(yè)務(wù)成功，例如能夠通常被我們稱為“無差別承載性”活動組件，這些活動必須完成，但本身無法提供任何競爭優(yōu)勢。對于大多數(shù)企業(yè)來講，此類任務(wù)包括服務(wù)器管理、負(fù)載均衡以及安全補丁應(yīng)用等等。我們在2014年提出了“無服務(wù)器”概念，并同時發(fā)布了AWSLambda。AWSLambda是一種計算服務(wù)，能夠幫助大家在無需配置或者管理服務(wù)器務(wù)交給AWS負(fù)責(zé)以幫助客戶專注于優(yōu)化自己的“獨門絕技”。事實上，這放精力，將時間投入到真正的業(yè)務(wù)與眾不同的方面例如產(chǎn)品亞馬遜CTO的“中臺論當(dāng)我們說起“無服務(wù)器”時，我們指的是在無需分神于基礎(chǔ)設(shè)施配置或按使用量計費的方式。無服務(wù)器不只有Labda，它是一套完整的應(yīng)用程應(yīng)用程序堆棧通常由以下三大要素組成像AWSFargate這樣的計算服務(wù)，用于運行應(yīng)用程序邏輯像MySQL以及PostgreSQL關(guān)系數(shù)據(jù)庫這樣的數(shù)據(jù)方案，也可以使用AmazonAurora等實現(xiàn)數(shù)據(jù)的持久駐留；類似于事件總線AmazonEventBridge這樣的集成層，用于實現(xiàn)數(shù)安全性：每個人都有責(zé)過去，很多企業(yè)都把安全視為一種神奇的“調(diào)味料”在應(yīng)用程序準(zhǔn)土，因此組織必須采取新的安全方法，圍繞整個應(yīng)用程序構(gòu)建起防火再是安全團隊自己的責(zé)任相反，安全深深融入到開發(fā)生命周期的每個階安全性將被整合至代碼庫、build管理程序乃至部署工具當(dāng)中。這既使用無服務(wù)器服務(wù)的情況下，安全狀態(tài)的難度更低，這是因為底層基礎(chǔ)設(shè)施的安全運營工作包括系統(tǒng)版本更新、軟件修復(fù)與等都現(xiàn)代化之 段推動云資源優(yōu)化。Yelp等客戶也采取了類似的現(xiàn)代化方式。對于以托管應(yīng)用程序作為起點的客戶，最常見的方法自然是重新托管，即“將應(yīng)用程序直接遷移至云端”。在此之后，很多客戶開始進一步探索云環(huán)境中的托管服務(wù)，嘗試將數(shù)據(jù)庫與API管理等任務(wù)遷移至WS，從而保證將自己的工作重心放在業(yè)務(wù)邏輯身上。確方法，因為在AWS平臺上，各種各樣的應(yīng)用程序都能夠以不同的狀態(tài)夠?qū)徱曌陨碚w業(yè)務(wù)優(yōu)勢，特別是對時間與資源的優(yōu)化分配。他們將時間花在定義業(yè)務(wù)邏輯上，擴展系統(tǒng)以輕松滿足期客戶需求，提高敏以向汽車買家提供車輛信息的 新功能的推出時間由六個月縮短至一周。初創(chuàng)企業(yè)Bynder公司也將產(chǎn)品而這，正是現(xiàn)代應(yīng)用程序的力量所在如何將代碼部署時間減95作者：EvanLimanto譯者本本文作者所在的公司Plaid是一家金融科技公司，該公司搭建了司的發(fā)展，基礎(chǔ)設(shè)施規(guī)模在不斷擴大。目前，這家公司運行著20多個服務(wù)，每天在服務(wù)上部署50多個代碼提交。因此，最小迅速進行Bug修復(fù)并運行平穩(wěn)的連續(xù)部署系統(tǒng)。碼的能力。工程師要花至少30分鐘才能通過多個過渡環(huán)境和生產(chǎn)環(huán)境構(gòu)雖然我們計劃實現(xiàn)長期改進，比如將基于AmazonECS服務(wù)的基礎(chǔ)設(shè)施遷移Kubernetes上，但是，為了在短期內(nèi)提高迭代速度，有必要快速AmazonECS部署的高延我們的銀行集成服務(wù)由4000個Node.js進程組成，這些進程運行在的Docker容器上，這些容器托管并部署在Amazon的容器編排服務(wù)ECS上。在分析了我們的部署過程之后，增加的部署延遲歸結(jié)到三個不同的組件啟動任務(wù)會導(dǎo)致延遲。除了應(yīng)用程序啟動時間之外，ECS健康檢個過程的三個參數(shù)是interval、retry和startPeriod。如果沒有對健康檢查進行仔細調(diào)優(yōu)，容器可能會卡在“啟動”狀態(tài)，即使它們已關(guān)閉任務(wù)會導(dǎo)致延遲。當(dāng)我們運行ECS服務(wù)更新時，SIGTERM我們啟動任務(wù)的速度限制了部署的并行性。盡管umPercent參數(shù)設(shè)置為200%，但是ECSstart-taskAPI調(diào)用的硬限制是每個調(diào)用只能執(zhí)行10個任務(wù)，而且速度有限。我們需要調(diào)用400次才方法探我們考慮并試驗了一些不同的潛在解決方案，以逐步實現(xiàn)總體目標(biāo)通過修改健康檢查參數(shù)來調(diào)整ECS配置。我們嘗試通過減少neval和arPerod的值來加強健康檢查，但是ECS在啟動時將健康的容器錯誤地標(biāo)記為不健康，導(dǎo)致我們的服務(wù)無法完全100%（ECS部署緩慢在ECS集群中啟動實例，以便可以在部署期間同時啟動小的修改，我們就能夠在每個容器省大約5秒的時間。盡管這些更改將總體部署時間減少了幾分鐘，但是我們?nèi)匀恍枰獙oderequirecache是一個JavaScript對象，它根據(jù)需要緩存模塊。這意味著多次執(zhí)行er(f’或import*asfoofrom'foo’只會在第一次時請求foo模塊。神奇的是，刪除requirecache中的條目（我們可以使用全局require.cache對象）將迫使Node在下次導(dǎo)入模塊時從磁盤重新讀為了繞過ECS部署過程，我們嘗試使用Node的requirecache在運行時執(zhí)行應(yīng)用程序代碼的“熱重載”。一旦接收到外部觸發(fā)（其實現(xiàn)為銀行集成服務(wù)上的gRPC端點），應(yīng)用程序?qū)⑿麓a來替換現(xiàn)有的構(gòu)我們能夠消除ECS部署中存在的大部分延遲，優(yōu)化整個部署過程。在Plaiderdays（我們的 組工程師聚在一起，為我們所謂的“快速部署”實現(xiàn)了一個端到端的概念新構(gòu)建的Node代碼也試圖使失效緩存，那么器代碼本身將如何重新加載就不清楚了。（有法可以解決這個問題，就是使用NodeEventEmitter，但是會給代碼增加相當(dāng)大的復(fù)雜性）。更重要的是，還存最終解決方案：重新加載了自己的進程封裝器，它的名稱非常貼切，叫做Bootloader。Bootloader的包含設(shè)置日志管道、轉(zhuǎn)發(fā)信號和ECS元數(shù)據(jù)的邏輯。每個服務(wù)都是通過將應(yīng)用程序可執(zhí)行文件的路徑以及一系列標(biāo)志傳遞給我們沒有清除Node的requirecache，而是在預(yù)期的部署構(gòu)建后，使用特殊的退出代碼來調(diào)用process.exit實現(xiàn)服務(wù)更新。我們還在Bootloader中實現(xiàn)了自定義邏輯，以觸發(fā)使用此代碼退出的任何子進程的進程重載。與“熱重載”方法類似，這使我們能夠繞過ECS部署的成本并速部署”邏輯允許其推廣到在Plaid運行的任何其他服務(wù)。下面是最終解決方案Jenkins部署管道向銀行集成服務(wù)的所有實例發(fā)送RPC請求，指示應(yīng)用程序接收gRPC請求進行快速部署，并根據(jù)接收到的提交散列從AmazonS3構(gòu)建好的壓縮包。然后，它替換文件系統(tǒng)上的現(xiàn)有構(gòu)建，并使用Bootloader識別的特殊退出代碼退出。Bootloader看到應(yīng)用程序使用這個特殊的R”退出代碼退出，服務(wù)運行新的代碼下面這簡單說明了這個過程如何將代碼部署時間減少95%結(jié)我們能夠在3周內(nèi)交付這個“快速部署”項目，并將90%生產(chǎn)容器的部署時間從30多分鐘減少到1.5分鐘。如何將代碼部署時間減少95%的顏色）。如果注意下黃線，就可以看到它在12:15左右增長趨于平穩(wěn)，這個項目極大提高了Plaid集成工作的速度，允許我們更快地發(fā)布特性及進行Bug修復(fù)，并將浪費在上下文切換和監(jiān)視儀表板上的工程時間京東Flutter實踐京東ARES多端技術(shù)在2019年，F(xiàn)lutter推出了多個正式版本，支持的終端越來越多，使越來越多的研發(fā)團隊加入到Flutter的學(xué)習(xí)熱潮中，京東作為互聯(lián)網(wǎng)大廠之一也積極參與了Flutter的跨端方案研究。本文將介紹京東在Flutter上為什么考慮Flutter技術(shù)其實京東很早就開始研究并實踐跨端的開發(fā)解決方案，最早使用的是HybdApp的技術(shù)方案，從2015年底開始逐步轉(zhuǎn)向RN技術(shù)棧，目前應(yīng)該是業(yè)內(nèi)N技術(shù)平臺應(yīng)用最廣泛、配套設(shè)施比較完善的公司之一。從2018年中開始，我們也關(guān)注到了Fuer技術(shù)，最吸引我們的特性是高性RN技術(shù)相對不足的地方。高性能指的是復(fù)雜場景和交互下的渲染性能，兼容性指的是不同終端平臺上的布局和體驗andod平臺上尤其重要。Flutter隨著2018年底正式發(fā)布了Flutter預(yù)覽版本，京東也越來越多的研發(fā)團隊有用Flutter進行開發(fā)業(yè)務(wù)的訴求。我們正式啟動研發(fā)并發(fā)布了JDFlutter引擎。在Flutter引擎之上，我們做了額外的Flutter工程改造：對Flutter開發(fā)環(huán)境和dart代碼管理進行優(yōu)化，可以無APP中并支持自動化dart編譯打包，便于開發(fā)和調(diào)試。路由及多頁面管理：對原生頁面和?utter頁面實現(xiàn)了集中路由管理，擴展UI組件庫：支持的Material和Cupertino樣式不能滿足需求，埋點等等基礎(chǔ)能力的打通并提供了50+原生擴展API。Android端動態(tài)化支持：在Android端實現(xiàn)了動態(tài)化支持，可以線上熱更新業(yè)務(wù)。iOS端暫不支持動態(tài)化。目前京東商城、京東、京東到家、京東物流、7Fresh等APP都有業(yè)務(wù)采用JDFlutter進行開發(fā)。JDFlutter框架設(shè)基礎(chǔ)層：提供了Flutter的基礎(chǔ)組件支持，包括組件管理，狀態(tài)管業(yè)務(wù)層：即具體業(yè)務(wù)邏輯實現(xiàn)層，根據(jù)業(yè)務(wù)需要進行不同組件組合，實現(xiàn)業(yè)務(wù)頁面的快速開發(fā)組動界面的改變，更有利于數(shù)據(jù)的持久化和保存，同時也有利于UI組件的HybridRouter：主要解決Flutter和Native之間交叉跳轉(zhuǎn)的問題，減少內(nèi)存開銷，共享同一個FlutterEngine。編譯發(fā)布：優(yōu)化Flutter原有的編譯邏輯，管理依賴Flutter原生依賴關(guān)聯(lián)，打包Flutter和原生代碼，實現(xiàn)自動化構(gòu)建發(fā)布。資源管理：管理資源，將資源轉(zhuǎn)換成Flutter類，便于資源的操作，類似Andorid的R類；模版代碼生成：減少Flutter的代碼編寫，自動生成Flutter組件的JSON轉(zhuǎn)換：將JSON數(shù)據(jù)轉(zhuǎn)換成Fluttercode，并提供jsonJDFlutter業(yè)務(wù)開發(fā)實JDFlutter為業(yè)務(wù)研發(fā)團隊提供了全流程的開發(fā)解決方案配置混合Flutter和原生混合開發(fā)有兩種情況，其一，開發(fā)Flutter業(yè)務(wù)的同學(xué)，需要和原生做交互，因此需要有Flutter和原生的混合編譯環(huán)境；其二，使用原生SDK開發(fā)業(yè)務(wù)的同學(xué)，需要和Flutter業(yè)務(wù)一起集成打包，此時需對Flutter透明，以減少對Flutter編譯環(huán)境的依賴，并且，只依賴原生編譯環(huán)境即可，此時Flutter編譯成aar依賴，放入原生項目中即可。接下來，重點介紹Android和iOS的混合編譯環(huán)境配置。Androidfluttercreate-tmodule--orgcom.example在原生根項目的settings.gradle加入如下配置信//include':app' //assumedexistingcontentsetBinding(newBinding([gradle:this])) //newevaluate(new // // //在原生App模塊中加入?utter依dependenciesimplementation}這樣就可以原生項目一起編譯了具體可以參照文檔 Flutter-to-existing-這樣的方式雖可以滿足混編需求，但還不是特別方便，開還需要去AndroidStudio項目中進行編譯，比較麻煩，所以我們也可以把Flutter項目settings.gradle改造，在Flutter開發(fā)環(huán)境下直接運行包含原生//include":$projectName"project(":$projectName").projectDir=new這樣改造之后即可在FlutterIDE中直接編譯Flutter混合工程，并進需要注意Flutter中g(shù)radle編譯環(huán)境和原生編譯環(huán)境的一致性，如果不一iOS創(chuàng)建?utterfluttercreate-tmodule進入iOS工 ，初始化pod環(huán)境（如果項目工程已經(jīng)使用Cocoapods，跳過此步驟pod##在Podfile文件添加的新代碼flutter_application_path='/{fluttermodule eval(File.read(File.join(flutter_application_path,'.ios','Flutter','podhelper.rb')),binding)安裝pod打開工程(***.xcworkspace)配置buildphase，為編譯Dart代碼添加打開iOS項目，選中項目的BuildPhases選項，點擊左上角號按鈕，選擇NewRunScriptPhase，將下面的s添加到輸入框中：ROOT/packages/flutter_tools/bin/xcode_backend.sh”embedFlutter開發(fā)中使用的組件，一般公司會采用共享的方式，以避免重復(fù)開發(fā)，而Flutter組件共享，即需要使用pub倉庫。由于公司的業(yè)務(wù)組件不適合上傳到pub倉庫，因此，需要搭建倉庫，以解決各個業(yè)務(wù)研發(fā)團隊，對Flutter組件共享需要。感的同學(xué)可以研究下pub倉庫的源碼.org/，其對Cloud環(huán)境有很大的依賴，也可以基于.com/kahnsen/pub_server來搭建一個簡易版本的倉庫，以滿足上傳和功能，pub協(xié)議相對比較簡單，我們可以在源碼增加協(xié)議接口來實現(xiàn)運行$git $cd~/pub_server$pub~/pub_server$dartexample/example.dart-d/tmp/package-dbListeningonTomakethepubclientusethisrepositoryconfigureyours$exportPUB_HOSTED_URL=發(fā)布一個Flutter組件需要修改pubspec.yaml，增加以下內(nèi)name:o_plugin//plugin名稱descriptionAnewFlutterplugin.介紹version:0.0.1//版本號authorxxx homepage://組件的介紹頁publish_to:倉庫上傳地上傳時可以使用如下命令檢查代碼錯誤，并顯示出上傳 結(jié)pubpublish--dry-如果有不想上傳的文件，可以在根增加一個.gitignore文件來忽Flutter組件的依賴配置，在項目的pubspec.yaml中dependencies下name:url:version:這樣可以在公司實現(xiàn)Flutter組件共享，如果不想搭建自己的倉庫，也可以采用git依賴，配置如 refdev-branchFlutter業(yè)務(wù)的開發(fā)與調(diào)在FlutterIDE中編譯代碼調(diào)試會很方便，直接點擊debug按鈕即可進行代碼調(diào)試，如果是混合工Androidstudio或者xcode中運行的工程，將要調(diào)試的App安裝到中（安裝debug版本），連接電腦，執(zhí)行如下命令，同步Flutter代碼到設(shè)備的宿主App中$cd$flutter執(zhí)行完命令后會進行等待設(shè)備連接狀態(tài)，然后打開宿主App，進入Flutter頁面，看到如下信息提示則表示同步成功。zbdeMacBook-Pro:examplezb$flutterattachWaitingforaconnectionfromFlutteronMI5X...SyncingfilestodeviceMI Tohotreloadchangeswhilerunning,press"r".Tohotrestart(andrebuildstate),press"R".AnObservatorydebuggerandprofileronMI5XisavailableForamoredetailedhelpmessage,press"h".Todetach,press"d";toquit,press"q".打開可以查看調(diào)試信息，代碼改動可以按r來實時同步界面，如果改動沒有實時生效可以按R重新啟動Flutter應(yīng)用JDFlutter熱更新實大部分跨端框架，諸如ReactNative/Weex/H5等，基本都能做到隨Flutter因其AOT的設(shè)計，預(yù)想會很難達到這種靈活度，但技術(shù)上仍具有一定的可行性，正如我們在之前的Flutter介紹文章中提到的，按照先有的API設(shè)計，是可以支持熱修復(fù)的，但僅限于Android。的架構(gòu)上已經(jīng)支持了熱修復(fù)架構(gòu)，大家可以更新到1.2.1版本查看，但是的功能還比較弱，無法做到版本控制和回滾的靈活性，所以JDFlutter并沒我們可以首先一起看一下熱修復(fù)方案的設(shè)計原理Flutter1.2.1版本引入了DynamicPatch為了更清楚的了解熱修復(fù)的原理和過程，我們需要首先深入了 的業(yè)務(wù)包結(jié)構(gòu)和FlutterApp可以看到主體代碼集中在 中，除此之外還有少量端的框架java代碼及?utterso引擎庫外Flutter包的初始化流 頁面啟動時是如何加載這些代碼的呢？那就要從 的初化說起了，在頁面啟動前需要調(diào)用FlutterMain.startInitialization來做初始可以看到該初始化是要求在主線程完成的，另外主要完成了以下三點檢查asset下Flutter包的完整性，主要是上面介紹的一些包，一致有些文件沒有打包進去，然后會直接crash，就是在這里觸發(fā)的，具體解壓部分asset下的資源到data分區(qū)，以下是一些片段的代碼，那為什么要解壓呢？放在asset下也是可以通過assetManager的。這里應(yīng)該是從性能角度要求解壓的，因為頻繁的使用assetManagerasset是很容易造成多線程阻塞的，一旦阻塞了將會導(dǎo)致整個Flutter業(yè)務(wù)全部無法渲染，所以需要解壓一些的，而不是解壓了所有的資源(例如就沒有解壓)從代碼來看，先增加要解壓的庫 ，然后啟動task從中解壓庫到data分區(qū)對應(yīng)app數(shù)據(jù)下的app_?utter 其中res_timestamp文件用于標(biāo)記一些時間戳，算法比較固定，根據(jù)客戶端的安裝時間及app的versioncode生成，也就是說當(dāng)用戶打開Flutter頁面后這個值就是固定的，如果有任何修改引擎會默認(rèn)有變化，刪除現(xiàn)有app_?utter的包，重新解壓。上面是對Flutter程序加載的分析，最終Flutter頁面顯示是需要呈現(xiàn)在原生組件FlutterView中的，這個組件會和底層FlutterNativeView進行綁定，并最終運行上面說到的data分區(qū)的Dart代碼來渲染UI。如果使用的是FlutterActivity，則默認(rèn)FlutterView是全屏顯示，如需要定制頁面，需要自己設(shè)計Activity。熱修復(fù)實了解了這些，其實熱修復(fù)方案已經(jīng)呼之欲出，替換原有解壓后的app_?utter包，殺進程，然后重新加載Flutter頁面即可。這里我們可以做采用adb命令push一些修改過的并編譯的dart代碼到 先打開Flutter頁面，默認(rèn)會加載asset下的包，并解壓到data分區(qū)修改一個Flutter工程，并編譯代碼，最終在工my_?utter/.android/Flutter/build/intermediates/?utter/release中看到打包這么文件中只有?utter_assets和isolate_snapshot_data文件是包含業(yè)務(wù)代碼和的，其他部分基本不會變化，所以我們這里要替換的也就是這兩個，大家可以使用adbpush命令將資源文件push到對應(yīng)的data分區(qū)來做個實驗。adbpushmy_flutter/.android/Flutter/build/intermediates/flutter/release/isolate_snapshot_data/data/data/app包名/app_flutter關(guān)閉Flutter頁面，在Task中殺掉進程，回來后重新打開Flutter頁面就能看到改動的效果，資源是存放在?utter_asset 放到這個 ，同樣能更新際使用中替換還是有很多問題的。那是如何設(shè)計的呢？熱修復(fù)設(shè)計熱修復(fù)步FlutterSDK1.2.1中，提供了ResourceUpdater，用來做包的檢在頁面初始化時，檢查固定的更新有沒有業(yè)務(wù)升級包，從代碼來看，必須在manifest中打開該功能，設(shè)置從邏輯上來看，只有在頁面onResume或者App重新開啟的時候會下載升級包，整體是通過http請求完成的，整體實現(xiàn)代碼大家可以參考ResourceUpdater中DownloadTask的實現(xiàn)部分，這里就不細說了。每次init的時候都會觸發(fā)檢查data分區(qū)的app_?utter包，如果不存在就會從aaset解壓出來，而升級包的替換就是在這步完成 解壓，如果不存在還是從asset 是manifest.json文件，里面會包含buildNumber/baselineChecksum字段，同時也會對"isolate_snapshot_data","flutter_assets/isolate_snapshot_data"等文件做CRC32校升級后的版本時間戳是從配置的manifest.json文件中如何配置服務(wù)文章上部分介紹了怎么打開升級patch的功能，因升級涉及到服務(wù)端，那是怎么做到關(guān)聯(lián)到服務(wù)器的呢？其實原理比較簡單，需要配置客戶端的manifest文件的meta屬性，增加PatchServerURL，也就是我們服務(wù)的地址，以及模式PatchDownloadMode和加載模式PatchInstallMode，默認(rèn)是ON_NEXT_RESTART（下次初始化時）存在的缺過于定制化，全部在引擎完成，很難適配一些特殊的需求定制不支持現(xiàn)在比較主流的升級流程，諸如灰度和白等功能版本號的維度不好控制，同時不能做版本回滾等操作JDFlutter如何實現(xiàn)熱修JDFlutter的整體實現(xiàn)原理，其實和是一樣的，目前來看不修改引擎的前提下，只有這種方案最簡單，但是我們沒有使用的這套升級架構(gòu)，默認(rèn)關(guān)閉了patch功能，并框架之外實現(xiàn)了替換包和加載的服務(wù)端根據(jù)客戶端的唯一標(biāo)識支持了白和灰度下發(fā)升級包優(yōu)化和替換流程。Flutter的升級包一般有4-5M，而且從網(wǎng)絡(luò)易產(chǎn)生UI阻塞或者包異常。接入JDFlutter的客戶端包后，并不會直換文件，而是修改名稱后解壓到app_?utter，等待業(yè)務(wù)頁面重新打開或者重新初始化時再修改成Flutter標(biāo)準(zhǔn)名同時并發(fā)運行的Flutter頁面較多，需避免因為升級出現(xiàn)一些中間升級失敗或者后業(yè)務(wù)包有問題，出現(xiàn)無法加載的情況或者文線上出現(xiàn)大量異常后，可以指定對應(yīng)的Flutter業(yè)務(wù)執(zhí)行降級策略，讓該業(yè)務(wù)迅速降級到H5頁面。熱修復(fù)規(guī)Flutter業(yè)務(wù)包差量升級：現(xiàn)有的升級模式都是全量包覆蓋，即使壓縮后升級包還是很大，影響升級成功率及用戶流量，后續(xù)會采用一些diff工具，對比生成差量的patch，通過服務(wù)端下發(fā)后，在客戶端合并成完整包，升級后及時更新頁面：現(xiàn)有方案（包括標(biāo)準(zhǔn)升級方案）沒有辦法做到業(yè)務(wù)包或者替換業(yè)務(wù)包后及時刷新頁面，需要restart進程后未來展Flutter是非常出色的跨端開發(fā)技術(shù)，現(xiàn)在已經(jīng)取得了長足的發(fā)展。社區(qū)生態(tài)和框架成熟度也正在快速追趕RN。相信不久的將來，F(xiàn)lutter+RN一定會成為跨端開發(fā)平臺的絕代雙驕。京東ARES跨端團隊作為京東技術(shù)與數(shù)據(jù)中臺的多端技術(shù)平臺團隊，聚焦于跨端開發(fā)技術(shù)框架和平臺搭建，包括但不限于RN、Flutter、小程拼購等京東系A(chǔ)pp內(nèi)，幫助業(yè)務(wù)團隊低成本、快速開發(fā)自己的業(yè)務(wù)，Uber運營大型分布式系統(tǒng)三年經(jīng)驗作者：GergelyOrosz譯者：足GergelyGergelyUber公司內(nèi)負(fù)責(zé)支付系統(tǒng)的運營。他在這篇文章里本文翻譯自“OperatingaLarge,DistributedSysteminaReliableWay:PracticesILearned”，翻譯已獲得原作者GergelyOrosz。在過去的幾年中，我一直在構(gòu)建和運營大型分布式系統(tǒng)：Uber的支高負(fù)荷高可用系統(tǒng)的構(gòu)建和運營是多么富有性。就構(gòu)建系統(tǒng)這件事來說，它本身是非常有趣的。要規(guī)劃好當(dāng)流量增加10倍/100倍時系統(tǒng)該如更是令開眼界的經(jīng)歷。系統(tǒng)越大，定律“可能出錯的事終將出錯”就越適用。對于頻繁進的問題如硬件故障或不把有缺陷的代碼發(fā)布到生產(chǎn)系統(tǒng)，到連接數(shù)這篇文章是我在Uber工作期間，關(guān)于如何可靠地運營一套大型分布 大多數(shù)情況下是這樣的），還是運行在云端（Uber的系統(tǒng)有時候會擴展具體來說，我會談到以下話題 值班、異常檢測與告停服與事件管理流事后總結(jié)、事件回顧與持續(xù)改進的文故障切換演習(xí)、有計劃的停機、容量規(guī)劃與黑盒測SLO、SLA及相應(yīng)的報獨立的SRE團對可靠性做持續(xù)投深入閱讀建要知道系統(tǒng)是否健康，我們就要回答問題：“系統(tǒng)在正常工作嗎？”需要這事來就容易。基礎(chǔ)設(shè)施健康：如果一或多臺服務(wù)器、虛擬機負(fù)載過高，那分布式系統(tǒng)就會發(fā)生部分降級。服務(wù)要運行在服務(wù)器上，所以像CPU使用率、 做這樣的的，而且支持自動擴展。Uber有個很大的 服務(wù)健康：流量、錯誤、延遲。“后端服務(wù)健康嗎”？這個問題實健康提供著有價值的信息。我喜歡為它們各自設(shè)置專門的。構(gòu)建新服務(wù)時，使用合適的HTTP響應(yīng)，并相應(yīng)的編碼，這些都會提供很多關(guān)于系統(tǒng)狀態(tài)的信息。比如在客戶端出錯時返回4XX編碼，在服務(wù)端出錯時返回5XX編碼，這類很容易構(gòu)建，也很容易解讀。對系統(tǒng)延遲的值得多考慮一下。對于產(chǎn)品來說，目標(biāo)就是讓大多為平均延遲會掩蓋一小部分高延遲的請求。因此就經(jīng)驗來說，監(jiān)測P95、P99或P999（即95%、99%或99.9%的請求）的延遲指標(biāo)會更好。監(jiān)測這些指標(biāo)得到的數(shù)字可以回答這樣的問題：99%的人發(fā)出的請求會有多快得到響應(yīng)（P99）？1000個人發(fā)出請求，最慢能怎樣（P999）？如果有讀者對這個話題感，可以進一步閱讀文章latenciesprimer。上圖展示的是平均、P95和P99的延遲指標(biāo)。請注意，盡管平均延遲是低于1秒的，但有1%的請求花費了兩秒或時間才完成，這樣的事一是谷歌的書《SRE：運維》，另外是分布式系統(tǒng)的“四個黃金信號”。從中可以知道，如果你的面向用戶的系統(tǒng)只想監(jiān)測四個指標(biāo)的話，那么關(guān)心流量、錯誤、延遲和飽和度就好了。喜歡吃快餐的話，可以讀讀CndySrdharan的《分布式系統(tǒng)可觀測性》，里面到了其它一有用工具如與件日、指和有關(guān)最佳踐。業(yè)務(wù)指標(biāo)，但我們無法得知服務(wù)的行為是否符合預(yù)期，使得“業(yè)務(wù)可以照常進行”支付系統(tǒng)為例，一個關(guān)鍵問題就是：“人們用某種特別的支付方法，是不是已經(jīng)足夠可以完成一次旅行？”辨別出服務(wù)使能的業(yè)務(wù)事件，并對這些業(yè)務(wù)事件進行，這是最重要的步驟之一。們就得花很多心思，以Uber的可觀測性技術(shù)棧為基礎(chǔ)，努力地為自己定制這類。值班、異常檢測與告值班就是一個更廣的話題了：nceent雜志在這方面做得很棒，對值班問題進行了許多方面的探討。我特別傾向于把值班做為“誰構(gòu)建，誰負(fù)責(zé)我們團隊就負(fù)責(zé)自己構(gòu)建的支付服務(wù)的值班。因此不管什么時候發(fā)生了告警，值班工程師都會響應(yīng)并對問題進行處理。我們該如何從得出警告從數(shù)據(jù)中發(fā)現(xiàn)異常，這是一個巨大的，也是機器學(xué)習(xí)的用武之地。有許多第服務(wù)可以提供異常檢測功能。而且對于我們團隊來說了適合Uber用例的解決方案。位于紐約的可觀測性團隊還就Uber如何做異常檢測這個寫過一篇很不錯的文章。從我們團隊的角度看，我們會把我們的數(shù)據(jù)推送到他們的管道中，并收到不同信任程度的告警，然調(diào)節(jié)告警系統(tǒng)非常重要。對告警信息進行檢查，并標(biāo)記是否需要采取相Uber的值班例子，由位于的Uber開發(fā)者體Uber位于的開發(fā)者工具團隊開發(fā)了專門的值班工具，用于對告警進行注解，并對輪班進行可視化。我們團隊每周都會對上一周的值班停服與事件管理流設(shè)想一下，這周由你值班。半夜里來了個告警，你就要一下對于小型系統(tǒng)來說，停服不算什么煩，值班工程師可以判斷出發(fā)晰標(biāo)準(zhǔn)的故障廣播和溝通就成了故障順利解決的關(guān)鍵。曾經(jīng)發(fā)生過好幾個案例，告警看起來與我之前見過的似乎一點關(guān)聯(lián)都沒有，幸好起。事實上第二天回來上班再仔根本原因也未嘗不可立刻恢復(fù)生產(chǎn)，事后原因處障我會“腎上腺素激增”，想要直接把問題當(dāng)場解決掉。一般來說故障都是由某次新么做收益很小，損失卻很大。因為新的修復(fù)代碼必須盡快完成，那就只能在生產(chǎn)環(huán)境進試，這么做反而更加容易。事實上第二天回來上班再仔根本原因也未嘗不可事后總結(jié)、事件回顧與持續(xù)改進的文這里講的是一個團隊如何進行故障的后續(xù)處理。他們會繼續(xù)做次系統(tǒng)級的修剔的。Uber的事后總結(jié)模板已經(jīng)隨著時間的推移而演進好多個版本了，好的事后總結(jié)會對故障根本原因進行深入挖掘，得到改進措施來避免類似的故障發(fā)生，或者在下一次出現(xiàn)類似故障時可以快速檢測和恢復(fù)。我說的深入挖掘，不是說淺嘗輒止地知道“這次故障的原因是最近提交的代碼引入的缺陷，在代碼時沒能發(fā)現(xiàn)出來”就可以了，用“五個為什么”的思考技巧去深入挖掘，最終得出一個更有意義的結(jié)論。比如下面的例子： >缺陷是由某次提交的有缺陷的 >代碼者沒注意到這 >因為 >因為沒有測試賬號的話，為什么我們沒有測試賬號？因為現(xiàn)在的系統(tǒng)不支持的工程師們進行，并對其中的關(guān)鍵點提出意見。公司級的技術(shù)管理層故障切換演習(xí)、有計劃的停機、容量規(guī)劃與黑盒測線穩(wěn)定運行，這樣的投入又是至關(guān)重要的。我加入Uber公司之后才第一歷了幾次之后觀點慢慢發(fā)生了變化。我一直認(rèn)為，設(shè)計健壯的分布式ServiceA和ServiceB，每個數(shù)據(jù)中心運行著幾十上百個虛擬機，資源利用率是60%，告警的閾值是70%?，F(xiàn)在我們做一次切換，把數(shù)據(jù)中心A的流量全都切到數(shù)據(jù)中心B去。在這種情況下假如不部署新的服務(wù)器，數(shù)據(jù)中心B肯定處理不了這些流量。部署新服務(wù)器可能會需要很長時間，后端壓力所有可靠的分布式系統(tǒng)都需要具備在不對用戶體驗造成任何影響的情況下“應(yīng)該”，因為這樣的演習(xí)是檢驗分布式系統(tǒng)網(wǎng)絡(luò)可靠性最有效的方法之一。戶、已知依賴比較少的服務(wù)來說，做這樣的練習(xí)相對簡單。但關(guān)鍵系以Uber為例，一個很明顯的黑盒測試用例就是在城市的范圍內(nèi)檢測乘車者與的匹配是否正常。即在某個特定的城市里，乘車者通過Uber發(fā)起的請求是否能得到的響應(yīng)，并完成一筆載客生意。當(dāng)這個式系統(tǒng)的定義是指那些每個月要支出幾萬甚至幾十萬的計算與系并非難事。另外一件重要的事就是，要挑選供應(yīng)商并鎖住云服務(wù)提供商的折扣。如果你的服務(wù)支出很大，而你又忽略了容量規(guī)劃，那你就SLO、SLA及相應(yīng)的報SLO意味著服務(wù)等級目標(biāo)（ServiceLevelObjective），是系統(tǒng)可用SLO，比如容量目標(biāo)、延遲、準(zhǔn)確度、可用性等。這些SLO可以用于觸SLO500250050-p99500-業(yè)務(wù)級SLO或功能級SLO是對上面這些服務(wù)的抽象。它們會包括直接影響用戶或業(yè)務(wù)的指標(biāo)。比如一個業(yè)務(wù)級目標(biāo)可以這么定義：希望99.99%的郵件可以在一分鐘之內(nèi)確認(rèn)發(fā)送成功。這個SLO也可以與服務(wù)級SLO相對應(yīng)（比如支付系統(tǒng)和郵件接收系統(tǒng)的延遲），也有可能會用服務(wù)等級協(xié)議（SLA，ServiceLevelAgreement）是服務(wù)提供者與服務(wù)“支付系統(tǒng)99.99%可用”可以做為一個SLA，它可以繼續(xù)分解為各個支撐系統(tǒng)的特定SLO。定義了SLO之后，下一步就是對它們進量并報告。對SLA和SLO進行自動化的測量和報告，這是個復(fù)雜的目標(biāo)，會與工程和業(yè)務(wù)團隊的優(yōu)先級相。工程團隊不會感，因為他們已經(jīng)有了各種不同級別的，可以實時地檢測故障。業(yè)務(wù)團隊也不會感，他們更希望把SRE團站點可靠性這個詞大概在2003年出自谷歌，谷歌公司現(xiàn)在已經(jīng)有了超過1500名SRE工程師。因為運營生產(chǎn)環(huán)境的任務(wù)越來越復(fù)雜，越來越快速成長的技術(shù)公司一般會比較早成立SRE團隊，他們會有自己的演進路線。Uber的SRE團隊成立于2015年，任務(wù)是對系統(tǒng)復(fù)雜度進行持續(xù)管理。別的公司在成立專門的SRE團隊同時，也可能成立專門的基礎(chǔ)設(shè)有了SRE團隊，他們就會從運營的角度考慮，讓運營大型分布式系統(tǒng)的工作變得更輕松。SRE團隊可能會有標(biāo)準(zhǔn)的和告警工具。他們可能會或自己構(gòu)建值班相關(guān)工具，可以為值班的最佳實踐提供建議。他他們會驅(qū)動選擇、定制和構(gòu)建標(biāo)準(zhǔn)工具，來定義和測量SLO不同的公司需要SRE團隊解決不同的痛點，所以不同公司的SRE團讀書，想深入了解SRE的話可以讀一下。把可靠性做為持續(xù)投組織，比如一家醫(yī)院。要讓一家醫(yī)院運營良好，就要不斷地做驗證和檢（、告警、黑盒測試等）。新員工和新設(shè)備會不斷投入進來：對醫(yī)院全職工作，對效率的測量和報告也變得很重要。因此大型醫(yī)院就會有靠基礎(chǔ)設(shè)施、SRE等支持團隊。深入閱讀建書《SRE：運維來自谷歌的非常棒而又免費的書。其“控分布式系統(tǒng)”一章的內(nèi)容與本文密切相CindySridharan寫的《分布式系統(tǒng)可觀測性》：這是另一本非常棒的MartinKleppmann博士寫的《設(shè)計數(shù)據(jù)密集型應(yīng)用》：這是迄今為止資Increment雜志的值班話題：這是一系列的文章，內(nèi)容聚焦于亞馬 、谷歌和Net?ix等公司的事件響應(yīng)流程。點擊這里查看HackerNews上對這篇貼子的留言Dropbox如何用400代碼檢作者：JukkaLehtosalo譯者：核子可 Python的大用戶之一Dropbox公了數(shù)百萬Python代碼，動態(tài)類型的存在讓代碼越來開始利mypy逐步將代碼轉(zhuǎn)換為靜態(tài)類型。雖然效果得到了充分驗證，但整個過程充滿了各種錯誤和失敗。本文，Dropbox公司完整輸出了從項目研究到實踐的Python靜態(tài)檢查全過程，以期對各位開者有所幫助事實上，Python已經(jīng)成為Dropbox公司使用范圍最廣的語言，其廣泛適用于后端服務(wù)與桌面客戶端應(yīng)用程序等（當(dāng)然，Dropbox公司也在大量使用Go、TypeScript以及Rust等語言）。在Dropbox公司數(shù)以百萬計的Python代碼行中，動態(tài)類型的存在讓代碼越來越難以理解，并嚴(yán)重影響生產(chǎn)力水平。為了緩解這一問題，Dropbox公司一直在利用mypy逐步將代碼轉(zhuǎn)換為靜態(tài)類型（順帶一提，mypy可能是目前Python當(dāng)中最流行的獨立類型檢查器，屬于開源項目，其開發(fā)團隊來自于Dropbox。）。截至目前，Dropbox已經(jīng)在成千上萬個項目當(dāng)中使用mypy，而且效果都得到了很好地驗證。但對于此次全方位檢查Python代碼，DropboxDropbox將向大家Python靜態(tài)檢查之旅從最早的學(xué)術(shù)研究項目，到現(xiàn)在逐步讓類型檢查與類型提示成為Python社區(qū)中眾多開發(fā)的常規(guī)操作。現(xiàn)在，已經(jīng)有多種工具支持類型檢查功能，包括各類IDE與代為什么要進行類型檢查如果開發(fā)者只使用過動態(tài)類型的Python，當(dāng)然有可能對靜態(tài)類型以mypy感到陌生。甚至，不少開發(fā)者就是因為動態(tài)類型而喜歡上Python，往開發(fā)經(jīng)驗告訴我們，理解代碼內(nèi)容就成了保障開發(fā)工作效率的關(guān)鍵數(shù)，或者可能的返回值類型）就會成為一題。以下是幾個在缺少類型注釋時，開發(fā)難以回答的典型問題：這個函數(shù)能返回None嗎這里的items參數(shù)是干什么用的id屬性是什么類型：到底是int、str、抑或是自定義類型這個參數(shù)需要的是一份、一個元組還是一個組classResource:id:bytesdef

items:Sequence[str])->read_metadata并不會返回Noneitems參數(shù)代表一系列字符串，其不可能隨意迭代id屬性為字節(jié)字符完全信任其中的內(nèi)容例如內(nèi)容含糊不清或者不夠準(zhǔn)確，因此帶來巨大的雖然Python在項目早期與中期階段表現(xiàn)良好，但當(dāng)項目發(fā)展到特階段后，成功的項目與使用Python語言的企業(yè)可能一個關(guān)鍵性決定：類似mypy這樣的類型檢查器主要負(fù)責(zé)提供用于類型描述的形式語言，當(dāng)然，除此之外，類型檢查器還可帶來其它助益類型檢查器能夠發(fā)現(xiàn)許多微妙（以及不那么微妙）的bug。其中的典型例子，就是開發(fā)者忘記處理的None值或者其它一些特殊條代碼。我們不需要進行100% 即使是在大型項目中，mypy也能夠在幾分之一秒內(nèi)完成完整的類型檢查。運試通常需要幾十秒或者幾分鐘。類型檢查帶來的脆弱且難以的單元測試，用以模擬及修復(fù)現(xiàn)有代碼以獲取快以PyCharm以及VisualStudioCode為代表的IDE和編輯器可利用檢查工具。當(dāng)然，像mypy這樣的獨立工具仍有助于保證注釋與啟動遷移：性能成為瓶在Dropbox，我們成立了一個三人小隊，從2015年底開始研究mypy。成員分別是Guido、GregPrice以及DavidFisher。從那時起，工作開始快速推進。首先，在mypy采用面前的最大就是性能。在將其運行在CPython解釋器上，這對于mypy這樣的工具來說速度有點不夠用。（作為包含JIT編譯器的Python替代性方案，PyPy在這方面也幸運的是，我們實現(xiàn)了一系列算法層面的改進。我們采用的第一項都與mypy運行前的狀態(tài)毫無區(qū)別，那我們完全可以使用前一次運行的緩mypy則在此基礎(chǔ)上更進一步：如果模塊的外部接口沒有改變，mypy甚至往涉及mypy的大量迭代運行，用以處理陸續(xù)且逐漸細化的類型。最初的mypy運行仍然相當(dāng)緩慢，這是因為它需要處理大量依賴項。為此，我們實現(xiàn)了緩存。如果mypy檢測到本地緩存可能已經(jīng)過期，mypy將從集中庫整個代碼庫的緩存快照。在此之后，它會以到2016年底，Dropbox公司已經(jīng)有大約42萬行Python完成了類型注釋。很多用戶都熱衷于類型檢查，而mypy的使用則在Dropbox各團隊期進行用戶，借以找出痛點，并確定需要優(yōu)先考慮的工作（這種直到今天也一直被保持下來）。其中，有兩項請求始終最高：更大的類型檢查覆蓋范圍以及更快的mypy運行速度。很明顯，我們的性能性能提升方法一：使用mypy守護進增量構(gòu)建雖然提升了mypy的速度，但仍然沒有達到頂峰。大量增量運行可能需要一分鐘的處理時長。對于任何面對大型Python代碼庫的用我們擁有數(shù)百個模塊，模塊相互間接導(dǎo)入。如果導(dǎo)入周期的任何文件發(fā)生變更，那么ypy此周期內(nèi)導(dǎo)入該模塊的所有其它模塊。其中最臭名昭著的循環(huán)就是“糾結(jié)（tangle）”，它給Dropbox帶來了很煩。其中一度包含有數(shù)百個模塊，辦法即使存在這種“糾結(jié)”，我們同樣可以提升mypy速度。答案就是，使用mypy守護進程。守護進程是一項服務(wù)器進程，負(fù)責(zé)執(zhí)行兩項非常重首先，它將關(guān)于整體代碼庫的信息保存在內(nèi)存中，這樣每次mypy運函數(shù)與其構(gòu)造之間的細粒度依賴關(guān)系。例如，如果函數(shù)foo調(diào)用函數(shù)bar，那么就存在一項從bar到foo的依賴關(guān)系。當(dāng)文件發(fā)生變更時，守護外部可見變更，例如變更的函數(shù)簽名。守護程序所采用的細粒度依賴?yán)頇C制，能夠確保只重新檢查實際變更的那些函數(shù)換言之，只檢查極實現(xiàn)上述目標(biāo)當(dāng)然是個巨大的，因為我們最初的mypy實現(xiàn)方案只適合一次處理一個文件。但在實際需求發(fā)生變化之后例如當(dāng)某個類性能提升方法二：將Python配合之前提到的緩存，mypy守護進程幾乎完全解決了增量類用性能表現(xiàn)仍然遠未達到最佳狀態(tài)。進行一次徹底的mypybuild可能需要在現(xiàn)有代碼當(dāng)中添加類型注釋，因此情況每周都在。我們的用戶渴望因此，我們決定延續(xù)mypy立項之初的重要想法將Python編譯為C。遺憾的是，Cython（一款現(xiàn)成的Python到C編譯器）并不能提供任何顯著的加速效果，因此我們決定從零開始編寫編譯器。由于mypy代碼庫（使用Python編寫）已經(jīng)全面完成類型注釋，因此利用這些注釋來各類微基準(zhǔn)測試中將性能提升了10倍以上。我們的想法是將Python模塊編譯為CPythonC擴展模塊，并將類型注釋轉(zhuǎn)換為運行時類型檢查（在運行時中通常被忽略的類型注釋，類型檢查器使用）。我們開始著手將mypy實現(xiàn)由Python遷移至真正的靜態(tài)類型語言，這恰好與Python的遷移思路完全匹配。（這種跨語言遷移正成為新的常態(tài)，mypy最初由Alore編寫，但后來則轉(zhuǎn)換為Java/Python自定義語法的混合體。CPython擴展API的定位，是保持項目整體可管理性的關(guān)鍵所在。我們不需要實現(xiàn)虛擬機或者mypy所需要的任何庫。此外，我們?nèi)匀豢梢岳靡磺性蠵ython生態(tài)系統(tǒng)與工具（例如pytest），并能夠在開發(fā)期間繼續(xù)使用經(jīng)過解釋的Python代碼，從而實現(xiàn)極快的編輯測試周期且不必這款被我們命名為mypyc的編譯器（因為它利用mypy作為前端來執(zhí)約4倍的運行性能提升。mypyc項目的開發(fā)在小團隊的推動之下用了大約4個月即告完成，團隊成員包括MichaelSullivan、IvanLevkivskyi、HughHan和。很明顯，這里的工作量遠少于使用C++或者Go完全重寫mypy，相關(guān)影響也要小得多。我們希望mypyc最終能夠被交付至Dropbox的其他工程師手上，供他們編譯并加速自己的代碼。能工程方法。編譯器可以利用快速、低級C構(gòu)造實現(xiàn)眾多操作的加速。例如，對某個已編譯函數(shù)的調(diào)用會被翻譯成C函數(shù)調(diào)用，而后者要比調(diào)的CPythonCAPI調(diào)用，從而略微提升編譯時的調(diào)用速度。總而言之，我我們還進行了一系列分析工作，希望了解“慢速操作”中的普遍共性。ypyc為這些操作生成速度更快的C代碼，或者利用更快的操作方式重寫相關(guān)Pyhon代碼（有時候確實沒什么好辦法，只能硬著頭皮重寫）：檢查400萬行在完成上述工作后，還一個重要（也是mypy用戶中排以實現(xiàn)這項目標(biāo)：從有機增長，到專注于mypy團隊的手動調(diào)整，再到靜結(jié)果就是，我們在最大的Python庫（后端代碼）中的注釋行數(shù)在大約三年之內(nèi)增長至近400萬行，這些全都遷移成了靜態(tài)類型代碼。mypy現(xiàn)在支持多種覆蓋報告，能夠幫助我們輕松相關(guān)進度。具體來講，我們可以報告各類不夠明確的類型來源例如在注釋中使用的顯式、檢查的類型，或者未進行類型注釋的已導(dǎo)入第庫等。為了在Dropbox當(dāng)中改善類型檢查精度，我們還在Python類型庫中為不少流行的開源庫提供經(jīng)過針對性改進的類型定義（即stub文件）。我們實現(xiàn)了（并在后續(xù)PEP當(dāng)中標(biāo)準(zhǔn)化了）新的類型系統(tǒng)，旨在為某些慣用的Python模式提供更精確的類型。其中一個典型例子正是TypeDict，其負(fù)責(zé)提供JSON類字典類型。字典當(dāng)中包含一組固定的字符統(tǒng)，同時考慮改進對Python數(shù)字堆棧的支持能力。以下是Dropbox在提升注釋覆蓋率時，設(shè)定的工作要點補充注釋的同時，在新的Python文件中使用類型注釋。外展。我們與各團隊就mypy進行交流，以幫助他們快速上手這。我們定期進行用戶以找到最重要的痛點，并竭盡全力解決這些問題（甚至可以發(fā)明一種新的語言來加快mypy的速度性能。我們通過mypy守護程序與mypyc改進了mypy性能（p75獲得高達44倍的性能提升），從而減少注釋流程中的阻礙，并允編輯器集成。我們?yōu)镈ropbox流行的各款編輯器提供了mypy運行集成，具體包括PyCharm、Vim以及VSCode等。這使得注第庫支持。我們的不少代碼都用到了SQLAlchemy，它使的很多動態(tài)Python函數(shù)無法由PEP484類型進行直接建模。為此，我們制作了一個PEP561stub文件包及一款開源mypy插件以提供經(jīng)驗總結(jié)檢查400萬行代碼絕非易事，我們在整個過程中遇到不少挑戰(zhàn)，當(dāng)然也犯過錯誤。下面，總結(jié)經(jīng)驗教訓(xùn)，希望能給大家?guī)韱⑹疚募G失。起步之初，我們的mypy版本只需處理少量或者說，從未接觸過buid之外的一切。在添加第一條注釋時，文件被隱式添加到bud當(dāng)中。如果從bud外部的模塊導(dǎo)入任何內(nèi)容，則會獲得Any精度大打折扣，并在遷移早期給我們帶來了不少麻煩。雖然現(xiàn)在已經(jīng)解決了，而且也算是一種典型做法，但在最糟糕的情況下，如果兩個孤立的類型檢查機制被合并起來，而這兩種機制之間又互不兼容，那么我們就必須對注釋進行大量更改！回想起來，我們應(yīng)該盡早將基礎(chǔ)庫模塊添加到y(tǒng)pyuild中。注釋遺留代碼。在剛剛開始時，我們面對著超過400萬行的現(xiàn)有Python代碼。很明顯，對如此規(guī)模的代碼進行注釋是項浩大的工程。我們編寫了一款名為PyAnnotate的工具，它能夠在運試的同時收集類型，并根據(jù)類型結(jié)果類型注釋但最終這款工具并沒能得到廣泛采用。整。我們也考慮過在每一次build測試時對一小部分實時網(wǎng)絡(luò)請求自動運導(dǎo)入周期。導(dǎo)入周期（也就是「tangle」或者說糾結(jié)周期）的存在令mypy提速變得非常。我們還需要努力讓mypy支持來自導(dǎo)入周期的各種。我們最近剛剛完成了一個重大項目的重新設(shè)計，最終解決了Alore語言。Alore的語法使得導(dǎo)入周期的處理變得更輕松。當(dāng)然，我們也Python之所以很難搞定導(dǎo)入周期，是因為其語句當(dāng)中可能指代多種事物。例如，賦值可能實際上定義了一個類型別名，而且mypy在大部分導(dǎo)入周結(jié)束從早期原型設(shè)計到如今對400萬行代碼進行類型檢查，這是一段漫長的旅程。在過程當(dāng)中，我們對Python的類型提示進行了標(biāo)準(zhǔn)化，建立起圍繞Python類型檢查發(fā)展出的新興生態(tài)系統(tǒng)、為IDE與編輯器開發(fā)出類雖然在Dropbox公司，類型檢查已經(jīng)被視為一項必要工作，但我自己的大型Python項目中使用類型檢查，那么現(xiàn)在就是最好的時機而言之，類型檢查助Python成長為一款更適合大型項目的出色語言DockervsKubernetes，容器生態(tài)圈現(xiàn)狀如作者作者對于近兩年的容器圈，Kubernetes可以說是主角，其增長速度遠超大家預(yù)期，毫無爭議地贏得了容器化管理和協(xié)調(diào)的，容器生態(tài)圈基本已定。但是容器技術(shù)還有不成地方，Kubernetes在全方位上也還有一定難度；整個容器生態(tài)市場中，Docker公司的熱度已經(jīng)在慢慢消退，以往的老對手VMware也在進軍容器市場，目前容器生態(tài)圈和容器技術(shù)態(tài)勢如何，Kubernetes發(fā)展良好的趨勢下還什么問題？InfoQ借此機會采訪了老師為我們解讀容器生態(tài)圈的現(xiàn)狀。Docker前路如Kubernetes已經(jīng)贏得了容器編排戰(zhàn)，越來越多的提供商在擁抱Kubernetes。而2018年3月份，在Docker公司剛滿五周歲的時候，創(chuàng)始人Solomon宣布離職，的人開始質(zhì)疑Docker。但是了，Docker公司才是這些“擁抱Kubernetes的提供商”最具有分量的那位。更何況早在一年前，Solomon就已經(jīng)開始不負(fù)責(zé)Docker公司的具體業(yè)務(wù)了，所以他的離任在公司層面不會產(chǎn)生太多影響。而Solomon此前在DockerCoreOS等競爭對手，也曾一度籠罩在Docker公司賭贏的中。即使到了最后，做出犧牲的只是Swarm等幾個具體項目，Docker公司還是完成而另一方面，Docker公司一向擅長的開發(fā)者關(guān)系工作，依然保持著迫于形勢Docker公司目前主要專注于企業(yè)服務(wù)等更加現(xiàn)實的業(yè)務(wù)上，一旦有某些公有云廠商回過神來，Docker公司的這部分價值會立即凸顯出在技術(shù)層面上，containerd項目距離成為Kubernetes下一代默認(rèn)容器運行時只差了一層窗戶紙。LinuxKit項目則成功牽制了Unikernel的崛起勢頭，還進一步完成了DockeronMac和宿主操作系統(tǒng)封裝的重要任務(wù)。如果說Docker公司的勢頭在2015年到2016年期間達到了巔峰，那么現(xiàn)Docker公司的巔峰，已經(jīng)了現(xiàn)有任何基礎(chǔ)設(shè)施領(lǐng)域開源公司所能達相比Kubernetes項目的強勢崛起等因素，CoreOS公司提前被收購才是目前Docker公司的現(xiàn)實。作為Kubernetes社區(qū)的標(biāo)桿玩家，CoreOS的收購案幾乎劃定了這一領(lǐng)域并購的天花板。在這樣的背景下，Docker公司要突破這個天花板倒不算，但要重現(xiàn)當(dāng)年微軟40億美金Kubernetes的技術(shù)作為基礎(chǔ)設(shè)施領(lǐng)域的系統(tǒng)軟件，工作層級太低是目前Kubernetes在更這就好比在，我們所熟知的基礎(chǔ)軟件如MapReduce，GFS，Dapper，BigTable，Spanner等都依賴于Borg的存在。Kubernetes的工作層次使得它在的過程中表現(xiàn)出來的侵入性非常強。很難去真正接管用戶的基礎(chǔ)設(shè)施體系來發(fā)揮出它的“容器化“能力。另一方面，很多團隊（包括很多技術(shù)能力很強的團隊）在Kubernetes項目的過程中也存在一些誤區(qū)，比如依然試圖按照“試點測試”、“定制開發(fā)”、“推廣”的思路來在這個開源項目。而實際上，Kubernetes項目的乃在于它鼓勵的并不是單純的“用”，而是深入的“玩”。這也意味著，只有能“玩”好Kubenee，才能真正保證團隊在這次容器技術(shù)的浪潮中站穩(wěn)腳跟。事實上，無論 、RedHa、CoreOS，還是，都不是Kubenees的典型用戶，但這并不妨礙他們成為這個領(lǐng)域數(shù)一數(shù)二的“玩家”。這其中的微妙差異，正體現(xiàn)了所謂的基礎(chǔ)設(shè)施項目的“化”設(shè)計思路。Kubnees生態(tài)的體量來說，基本上不存在非常的狀況。但是如何能夠鼓勵用戶以“白盒”化的方式去“玩好”Kubernetes項目，改變目前用戶Kubernetes項目的思路，則是一個非常值得深入探討的話題?；旌显骗h(huán)境不是目前Kubernetes項目的主旋雖然Kubernetes創(chuàng)始人CraigMcLuckie說Kubernetes促成了多云，VMware也已經(jīng)和Pivotal還有Cloud合作推出了PKS(PivotalContainerService)，可以Kubernetes節(jié)點，適合多云環(huán)境，但是“跨混合云和多云環(huán)境”本質(zhì)上是與公有云巨頭，也就是Kubernetes和CNCF背所以不難理解，混合云的支持還不是當(dāng)前Kubernetes項目在技術(shù)上需要關(guān)心的重點。當(dāng)然，作為一個完全中立的Linux項目，生態(tài)參與者們?nèi)绾螌ubernetes應(yīng)用在混合云的環(huán)境中是一件完全自主的事情。這當(dāng)然也是Craig為之背書的主要原因：Heptio的解決方案必然是沒有廠商所以，在確保用戶只vendorlock在