建站
咨詢
售后
建站咨詢
新聞中心
作為一家初創(chuàng)公司，構(gòu)建軟件要堅持創(chuàng)新，要有吸引力和競爭力。因為，市場在不斷變化，新的需求也在不斷出現(xiàn)。
鹽田網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián)建站,鹽田網(wǎng)站設(shè)計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為鹽田1000+提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)網(wǎng)站建設(shè)要多少錢，請找那個售后服務(wù)好的鹽田做網(wǎng)站的公司定做！
從軟件角度來說，要保持這樣的優(yōu)勢就意味著必須盡可能縮短文檔和開發(fā)階段所占的時間。當(dāng)然，保持軟件的彈性也很重要，提供優(yōu)秀的服務(wù)是 Algolia 的重要目標之一。我們有許多高端用戶，搜索功能對業(yè)務(wù)有非常重要的影響，所以不能接受宕機時間，尤其是在黑色星期五之類的特殊時間段。
因此，開發(fā)者 必須在軟件的彈性與創(chuàng)新之間找到合適的平衡點。 這兩方面是相互牽制的：要讓軟件具有彈性，就要進行詳盡的測試，這會消耗大量精力，占用我們進行創(chuàng)新的時間。因此，一個比較好的折衷方案就是在生產(chǎn)環(huán)境進行測試。
為什么要在生產(chǎn)環(huán)境進行測試？
在生產(chǎn)環(huán)境進行測試就是把新代碼發(fā)布到生產(chǎn)環(huán)境中，直接用真實的生產(chǎn)數(shù)據(jù)和流量進行“測試”的過程。與之形成對比的就是運行全面的測試用例集。這個風(fēng)險很大，開發(fā)者的第一直覺肯定不要這么做。但隨著軟件規(guī)模的發(fā)展，你會發(fā)現(xiàn)進行詳盡的測試越來越不可能了。
讓我們看看 Algolia 引擎。我們有二十多個查詢參數(shù)。假設(shè)它們?nèi)?Boolean 類型，那么要運行的用例總數(shù)就會達到一百萬個，二十個參數(shù)，每個有兩個可能值，那就是 2^20 種可能的場景。
談到與測試相關(guān)的工作所要消耗的時間，有三方面要考慮：
- 寫測試用例的時間
- 維護測試用例的時間
- 運行測試用例的時間
寫出一百萬個測試用例來，這個工作量已經(jīng)很驚人了。一旦寫出來，它們就成了項目內(nèi)容的一部分。就像維護別的源代碼一樣，也要花精力去維護它們，所以每次軟件迭代所要做的事情就更多了。
假設(shè)你的團隊足夠大，有充足的人力可以編寫和維護這些測試用例，但運行它們一樣需要不少時間。假設(shè)運行每個測試用例只需要 10 毫秒，那全運行一遍就需要 2 小時 45 分鐘。不管代碼中有什么更新，都需要花 2 小時 45 分鐘才能驗證完。
客戶購買我們的產(chǎn)品不止是看中了當(dāng)前已經(jīng)具備的功能，更是看中了未來將會發(fā)布的功能。他們希望我們可以定期發(fā)布新功能，幫助他們成長，變得更容易創(chuàng)新和更具有彈性。因此，我們必須提升自己的效率。
在開發(fā)新功能時，我們只會寫些簡單的用例來驗證功能，并對明顯的邊界條件進行測試。要對功能進行全面驗證，我們會采取灰度發(fā)布的方式，直接在生產(chǎn)環(huán)境中進行測試。這樣即使代碼中有缺陷，也可以把對客戶的影響控制得盡量小。通過這樣的方法，我們就可以按時發(fā)布新功能了。
真實案例
以我們最近重寫的一個 Algolia 的核心功能做具體例子。如果要對它進行充分測試，就要用所有可能的 Unicode 字符（超過一百萬個）對這二十幾個參數(shù)組合成的一百萬個用例進行測試。這樣算起來總數(shù)會超過十億次。假設(shè)運行一個測試要用 10 毫秒，那完成全部測試內(nèi)容就要 11 天。
我們不得不尋找更好的解決方案。因此我們放棄了這十億次測試。不能因為這件事而顯著地拖慢我們的發(fā)布流程，我們決定在生產(chǎn)環(huán)境進行測試。
我們最大的顧慮就是可能對用戶造成的影響，因此我們定義了要把它部署出去所必須要做的事：
- 一個漸進式的發(fā)布流程
- 一種在好的基礎(chǔ)設(shè)施之上進行重試的方法
- 積極主動的問題檢測
所有通過我們的網(wǎng)站發(fā)往 Algolia 的請求，最終都是由一個集群來提供服務(wù)的，集群由三個節(jié)點組成。每個節(jié)點中都包含 100% 的數(shù)據(jù)，可以獨立響應(yīng)請求，因此可以提供健壯的部署方案。假設(shè)普通的服務(wù)器平均可用率為 95%，那這種方案可以提供 99.987% 的可用性。只有當(dāng)所有服務(wù)器全部宕機的時候，你的服務(wù)才會真的宕機。所以這種可能性是 5% x 5% x 5%，即可能會有 0.0125% 的宕機時間。
但即使是在這樣的架構(gòu)下，軟件的缺陷仍然可能造成服務(wù)中斷。因此，我們采取了漸進式的灰度發(fā)布方案。新的軟件全部發(fā)布完成需要三天的時間。這樣的部署策略給了我們足夠的時間來發(fā)現(xiàn)問題。
另外還有一點很重要的，就是我們的客戶端 API 會采用重試的策略。假如它正好把請求發(fā)往了一個有問題的節(jié)點，那么在請求失敗之后，它會自動尋找另一個節(jié)點進行重試，直到取得成功的響應(yīng)為止。因此最終用戶對這個問題是沒有感知的。
在我們部署新版本的高亮功能時，曾經(jīng)發(fā)生過一個標準化問題。我們的目標是把所有文本都轉(zhuǎn)化成標準化的格式，這樣就可以方便地對不同的輸入進行對比。一般來說，標準化后的內(nèi)容長度不會比輸入的原文更長，這也是高亮功能的前提。結(jié)果，我們卻發(fā)現(xiàn)有些字符在標準化之后長度會增加：字母?（德語）就會被標準化成了“ss”。在重寫的時候，我們增加了運行時前置條件檢查，以確保標準化后的長度比原來長度更小，或者相等。這段代碼發(fā)揮了作用，把這個問題暴露出來了。
當(dāng)我們把新版本代碼部署到第一個節(jié)點上時，對于那些標準化之后長度會增加的請求，它馬上就停止了響應(yīng)。幸虧我們的客戶端 API 有重試的功能，所以客戶沒有受到影響，沒有用戶注意到這一點。而在后臺，我們的監(jiān)控系統(tǒng)則發(fā)出了告警，所以我們馬上對發(fā)布進行了回滾，以保持整個集群的穩(wěn)定。通過這種辦法，我們?yōu)樽约籂幦〉搅俗銐虻臅r間來理解問題和完成代碼修復(fù)，并進行相應(yīng)的測試。
一種合適的部署方案
如果你也想在生產(chǎn)環(huán)境進行測試的話，有三個至關(guān)重要的前提條件：
- 可復(fù)制的基礎(chǔ)設(shè)施；
- 彈性的軟件；
- 安全的部署策略；
- 可復(fù)制的基礎(chǔ)設(shè)施
在現(xiàn)在這個時代，配置一套可復(fù)制的基礎(chǔ)設(shè)施是非常容易的：所有云服務(wù)商都可以在多個虛擬機的前面提供負載均衡。就我們公司的架構(gòu)來說，我們在整個集群的級別復(fù)制搜索引擎的數(shù)據(jù)，每個節(jié)點都 100% 地擁有全量數(shù)據(jù)。通過這種方式，每個節(jié)點都可以獨立完成對請求的響應(yīng)。
彈性的軟件
這一部分就要看你是怎樣構(gòu)建軟件的了。在 Algolia 引擎的代碼中，有許多關(guān)于健康狀態(tài)的檢查，會校驗函數(shù)的前置條件是否滿足，以及是否處于期望的狀態(tài)等。當(dāng)運行到非正常的狀態(tài)時，引擎就會停止處理，以避免返回有問題的數(shù)據(jù)。它會強制 API 客戶端在別的節(jié)點上透明地進行重試。
安全的部署策略
這一點被最后提到，但它也一樣非常重要。這里提到的部署策略的主要目標，就是要在逐步發(fā)布新版本軟件的過程同時，注意控制風(fēng)險。
Algolia 的基礎(chǔ)設(shè)施主要包括四個環(huán)境：測試環(huán)境、準生產(chǎn)環(huán)境、生產(chǎn)環(huán)境和安全環(huán)境。每個環(huán)境都有不同的 SLA：
測試環(huán)境只包含供內(nèi)部使用的集群。出故障時只影響公司內(nèi)部員工。準生產(chǎn)環(huán)境包含面向外部大眾用戶項目的搜索集群。生產(chǎn)環(huán)境包含我們客戶的集群。安全環(huán)境包含我們最重要的 SLA 客戶的集群。根據(jù)部署策略，我們通過使用多個不同的環(huán)境來降低風(fēng)險。也就是說，我們會先在對客戶影響最小的集群上進行部署。
除了不同的環(huán)境，我們還利用了三份復(fù)制這個特性，制定了如下的 12 步部署流程：
先部署到測試環(huán)境的所有三個節(jié)點上；部署到準生產(chǎn)環(huán)境的第一個節(jié)點上，再部署到生產(chǎn)環(huán)境的第一個節(jié)點，再部署到安全環(huán)境的第一個節(jié)點上；觀察一天；部署到準生產(chǎn)環(huán)境的第二個節(jié)點上，再部署到生產(chǎn)環(huán)境的第二個節(jié)點，再部署到安全環(huán)境的第二個節(jié)點上；再觀察一天；部署到準生產(chǎn)環(huán)境的第三個節(jié)點上，再部署到生產(chǎn)環(huán)境的第三個節(jié)點，再部署到安全環(huán)境的第三個節(jié)點上；第一步可以幫我們發(fā)現(xiàn)分布式系統(tǒng)內(nèi)部的處理集群里，節(jié)點之間交互的代碼問題。
接下來一個節(jié)點一個節(jié)點的部署，可以幫我們確認集群內(nèi)部是否可以同時支持兩個不同的版本，以及代碼是否足夠穩(wěn)定。
為什么在部署節(jié)點的過程之中有兩次要觀察一天呢？因為這樣可以讓我們有充足的時間發(fā)現(xiàn)性能問題、數(shù)據(jù)問題或需要長時間運行才能發(fā)現(xiàn)的問題。到這一步時，我們就已經(jīng)解決掉大部分問題了。接下來的部署步驟只是幫助我們發(fā)現(xiàn)一些可能的未知缺陷。
每當(dāng)發(fā)現(xiàn)新問題時，我們都會立刻將新版本代碼回滾。這樣我們提供的服務(wù)就可以恢復(fù)到一個穩(wěn)定的狀態(tài)，我們也可以有充足的時間去修復(fù)問題，并增加相應(yīng)的測試用例。
使用了這樣的方法，我們的測試用例集就是客戶的真實使用場景。這樣效率就非常高了，我們可以每周都發(fā)布新版本，滿足客戶的需求。盡管我們的代碼量已經(jīng)非常龐大，我們?nèi)匀蛔龅搅诉@一點。
好比完美更勝一籌
初創(chuàng)公司的生態(tài)環(huán)境是相當(dāng)嚴峻的。小團隊要找到高效的方法，打造出比大公司的大團隊更好的產(chǎn)品。
定期發(fā)布新功能的重要性，不亞于有著良好用戶體驗，可以滿足用戶需求的穩(wěn)定產(chǎn)品。選擇做足夠的測試還是選擇有足夠的測試覆蓋率并可以定期發(fā)布？對效率的需求逼著我們在這兩者之間找到了一個中間的平衡點。
在增加新測試用例時你必須特別小心，因為要消耗的時間太多了：要花時間去寫、去維護和運行。那你知道什么時候該寫測試嗎？90-90 法則適用于這種情況：測試一個功能 90% 的內(nèi)容是非常容易而直接的，再測試剩下的 10% 會花費相同的時間。所以根據(jù)客戶的使用情況來處理這剩下的 10% 非常重要，不應(yīng)該追求完全的覆蓋率。
為了降低風(fēng)險，請多花些時間對軟件和基礎(chǔ)設(shè)施進行設(shè)計，讓它們可以支持在生產(chǎn)環(huán)境進行測試，并把對客戶的影響限制到最小。
網(wǎng)頁名稱：初創(chuàng)公司技術(shù)困境：彈性部署與詳盡測試
標題URL：http://www.5511xx.com/article/djiosee.html
