成功者總是不約而同的配合著時(shí)代的需要，技術(shù)方案亦是如此。
我所在的公司已經(jīng)運(yùn)行六年了，期間經(jīng)歷了波峰成就了當(dāng)時(shí)的社會(huì)現(xiàn)象，也經(jīng)歷了波谷，現(xiàn)在正處在平穩(wěn)上升期。公司是團(tuán)購網(wǎng)平臺(tái)模式，技術(shù)上經(jīng)歷了三次大的重構(gòu)，庫表也都拆分完畢，前端是js+php，接口層是java系，數(shù)據(jù)庫是MHA。前端做了靜態(tài)化并分發(fā)到多家CDN，接口層面做了無狀態(tài)化并且用負(fù)載均衡做了集群，后端有DMP數(shù)據(jù)庫管理平臺(tái)為MHA護(hù)航。基礎(chǔ)設(shè)施監(jiān)控層面做了zabbix監(jiān)控和nagios報(bào)警聯(lián)動(dòng)，應(yīng)用層面做了kafka日志收集和nagios報(bào)警聯(lián)動(dòng)，整體架構(gòu)基本趨于完善。
但隨著時(shí)間的推移，硬件發(fā)展迅猛，新采購的服務(wù)器按照原有的方式部署就會(huì)有大量的浪費(fèi)，所以我們考慮更大程度的復(fù)用服務(wù)器。以前的復(fù)用方式是http級別的，基于虛擬主機(jī)方式。此方式有一個(gè)弊端就是發(fā)布一個(gè)虛擬站點(diǎn)，整個(gè)http服務(wù)要重啟，而且在高訪問量的情況下會(huì)出現(xiàn)服務(wù)重新加載慢的情況。解決此問題就需要隔離虛擬站點(diǎn)的服務(wù)，或者叫獨(dú)立虛擬站點(diǎn)的服務(wù)。經(jīng)過調(diào)研我們采用了docker容器化技術(shù)，成功的解決了隔離并且復(fù)用的問題。理論上在大批量docker化后，服務(wù)器會(huì)有大量空閑，所以我們要在做docker化的同時(shí)就考慮后續(xù)如何利用服務(wù)器。我們有兩個(gè)方向：一是做私有云，為公司使用，乃至可以為集團(tuán)使用；二是把空閑機(jī)器拆分，一部分完善docker在公司內(nèi)的生態(tài)環(huán)境，另一部分用于做大數(shù)據(jù)分析。經(jīng)過一系列的邏輯討論，最終我們采用了第二個(gè)方向。下面略述邏輯討論過程。
首先從實(shí)際角度考慮，當(dāng)接口層面docker化完成后，撤下的機(jī)器是否夠做云的。答案是由于機(jī)器過時(shí)嚴(yán)重，做云還需要采購關(guān)鍵節(jié)點(diǎn)機(jī)器，這樣就會(huì)增加成本。其次docker化同時(shí)就必須要做docker生態(tài)環(huán)境的建設(shè)，比如發(fā)布,監(jiān)控,負(fù)載均衡等等，這些都要和公司的實(shí)際情況相結(jié)合，不能只是照搬理論文檔的范式。而這些生態(tài)服務(wù)就需要更多的機(jī)器，他們是服務(wù)于docker的。再次，公司是團(tuán)購網(wǎng)平臺(tái)模式，內(nèi)部的BI部門是最能夠技術(shù)變現(xiàn)的部門，所以我們應(yīng)該加強(qiáng)他們的資源。
經(jīng)過半年的調(diào)研與實(shí)施，現(xiàn)在有一小部分接口項(xiàng)目在線上使用docker，生態(tài)還沒有完全建立，總之docker在我公司屬于蓬勃發(fā)展期。
熟悉我的朋友們會(huì)疑惑，為何經(jīng)過半年了只是幾個(gè)項(xiàng)目在使用，并沒有全面docker化。我給出的答復(fù)是：時(shí)代并沒有迫切需要。回到卷首，我們看到“成功者總是不約而同的配合著時(shí)代的需要，技術(shù)方案亦是如此。”此時(shí)很多架構(gòu)師會(huì)跳出來說，“注意，你危險(xiǎn)了，你目光短淺了，你墮落了······”我給出如下回復(fù)：技術(shù)確實(shí)是配合時(shí)代需要而產(chǎn)生并且實(shí)施的，如果過度超前實(shí)施，只能帶來反作用，很明顯的就是成本上升和復(fù)雜度翻倍。一個(gè)成熟的架構(gòu)師會(huì)目光如炬，適度超前實(shí)施，而且是明確實(shí)施的成果能夠轉(zhuǎn)化成為下一步的生產(chǎn)力的改造，在此前提下，犧牲一些復(fù)雜度和成本是可以理解的，但當(dāng)公司內(nèi)部的技術(shù)需求并沒有發(fā)展到迫切需要或者將要迫切需要改造的時(shí)候，成熟的架構(gòu)師一般會(huì)選擇無為而治，更有甚者叫做無為不治。很明顯，我上面的不做云做docker生態(tài)和大數(shù)據(jù)的方案也是出于適度的前瞻原則，并不是人云亦云，大家都做云了我們就要跟上時(shí)代做云，不做就如何如何了。說這樣話的架構(gòu)師永遠(yuǎn)不能帶領(lǐng)公司實(shí)現(xiàn)利益最大化。
所以，在架構(gòu)選型和架構(gòu)實(shí)施的時(shí)候應(yīng)該多思考，保持適度超前原則，否則就會(huì)事倍功半。還是那句話“成功者總是不約而同的配合著時(shí)代的需要，技術(shù)方案亦是如此?！?/p>
作者：李博謙
