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