摘要：本文介紹了企業(yè)互聯(lián)網(wǎng)開發(fā)及運(yùn)維的一些實(shí)踐，深入剖析了互聯(lián)網(wǎng)項(xiàng)目開發(fā)及上線過程中的各種痛點(diǎn)及解決之道。線上出錯(cuò)，我們通過收集服務(wù)器端應(yīng)用性能數(shù)據(jù)的方式，實(shí)時(shí)展示應(yīng)用的調(diào)用拓?fù)鋱D，并根據(jù)出現(xiàn)異常的請求，進(jìn)行下鉆，定位出具體出現(xiàn)問題的代碼。

本文介紹了企業(yè)互聯(lián)網(wǎng)開發(fā)及運(yùn)維的一些實(shí)踐，深入剖析了互聯(lián)網(wǎng)項(xiàng)目開發(fā)及上線過程中的各種痛點(diǎn)及解決之道。
一個(gè)互聯(lián)網(wǎng)項(xiàng)目的上線并不是那么容易，需要經(jīng)過很多的環(huán)節(jié)：從服務(wù)器的準(zhǔn)備開始，緊接著是業(yè)務(wù)系統(tǒng)的搭建，搭建的過程中涉及到操作系統(tǒng)、依賴中間件、應(yīng)用部署、配置修改等眾多事情；搭建完畢后，進(jìn)行業(yè)務(wù)的線上驗(yàn)證及各種場景的演練，并進(jìn)行高并發(fā)的壓力模擬測試，找出性能瓶頸，并不斷進(jìn)行問題修正、架構(gòu)調(diào)整；最后進(jìn)行災(zāi)備的演練，整理好自動化腳本，然后挑選災(zāi)備環(huán)境的某一組進(jìn)行上線試運(yùn)行，迎接上線運(yùn)行真實(shí)用戶壓力的考驗(yàn)。

回想每次新項(xiàng)目上線的過程，每次都是一次痛苦的折磨?；ㄙM(fèi)這么長時(shí)間，根源究竟是什么？答案就是這里面太多的環(huán)節(jié)都是依賴人工去處理。那么我們該如何縮短交付周期呢？

回到大家手上的互聯(lián)網(wǎng)項(xiàng)目，當(dāng)項(xiàng)目上線后，是不是就萬事大吉了呢？慶功后，更多的事情才慢慢到來，隨著業(yè)務(wù)的開展，用戶量漸漸增加，高并發(fā)的場景也開始凸顯。由于只是關(guān)注了業(yè)務(wù)系統(tǒng)本身的上線，與之相關(guān)的外圍支撐系統(tǒng)并沒有建設(shè)，這種狀況下，根本無法了解系統(tǒng)的內(nèi)部運(yùn)行狀況。當(dāng)前到底有多少用戶在訪問系統(tǒng)、每臺服務(wù)器正承受多大的壓力、當(dāng)前的業(yè)務(wù)量到底是多少？我們可以思考下，淘寶做雙11活動的時(shí)候，交易量是如何統(tǒng)計(jì)的？京東做618活動，實(shí)時(shí)流量又是如何統(tǒng)計(jì)的？我們應(yīng)該建設(shè)哪些外圍支撐，才能做到系統(tǒng)不是黑盒？

當(dāng)線上業(yè)務(wù)系統(tǒng)出錯(cuò)的時(shí)候，是不是經(jīng)常遇到無從下手的情況？這是因?yàn)殡S著業(yè)務(wù)規(guī)模的不斷擴(kuò)大，線上系統(tǒng)變的錯(cuò)綜復(fù)雜，就像圖中的電線一樣，稍有不慎，就會起火！可能是網(wǎng)絡(luò)問題、環(huán)境問題、代碼問題、第三方API的問題等等，想要定位問題需要各種不同的技術(shù)棧，調(diào)用鏈路的追蹤，沒有科學(xué)的依據(jù)，幾乎不可能。

當(dāng)線上出現(xiàn)的問題排解的差不多了，業(yè)務(wù)也穩(wěn)定了，新的問題又來了。用戶的活躍帶來了流量的井噴式暴增，稍有不慎就會導(dǎo)致系統(tǒng)崩塌。這個(gè)時(shí)候，需要進(jìn)行及時(shí)的擴(kuò)容，拯救系統(tǒng)。但往往事與愿違，機(jī)器準(zhǔn)備不到位、環(huán)境部署不夠快、業(yè)務(wù)擴(kuò)容不及時(shí)，導(dǎo)致擴(kuò)容的成本居高不下。

或者采取了自認(rèn)為“明智”的討巧做法，借用其他業(yè)務(wù)線的機(jī)器進(jìn)行了擴(kuò)容，但是你的業(yè)務(wù)系統(tǒng)跟兄弟系統(tǒng)環(huán)境是不一致的。新業(yè)務(wù)的侵入，導(dǎo)致了其他業(yè)務(wù)線環(huán)境的改變，反而造成了別的業(yè)務(wù)線癱瘓，真是城門失火、殃及池魚。我們急需一致化的環(huán)境進(jìn)行擴(kuò)容，Docker是我們的救兵。

面對如此多的問題，可以想象團(tuán)隊(duì)的狀況會是怎樣的？團(tuán)隊(duì)整天忙于救火，壓力非常大。很多時(shí)候?yàn)榱司然鸲然?，拆了東墻補(bǔ)西墻，代碼更是純粹為了解決問題而堆上去的，代碼管理混亂，技術(shù)積累缺乏……

在這種技術(shù)積累的情況下，老板又要開啟一條新業(yè)務(wù)線。由于沒有統(tǒng)一的項(xiàng)目模板，導(dǎo)致每次項(xiàng)目啟動都是底層代碼都要重寫一遍。模塊封裝不夠，導(dǎo)致本可以公用的模塊，每個(gè)團(tuán)隊(duì)都要重新封裝一次，研發(fā)資源的重復(fù)投入，使得研發(fā)成本居高不下。

為了使一切更規(guī)范起來，我們需要一個(gè)穩(wěn)定的底層支撐平臺，保證業(yè)務(wù)的快速發(fā)展。做到快速開發(fā)新提出的需求，不斷的迭代小版本，開發(fā)的過程中有一些通用的模板和經(jīng)過驗(yàn)證的技術(shù)組件直接套用。開發(fā)完成后，能夠快速部署上線，小版本持續(xù)集成。上線以后服務(wù)不要掛掉，出現(xiàn)問題能夠快速定位。流量暴增的時(shí)候，能夠及時(shí)感知，并實(shí)現(xiàn)快速擴(kuò)容。服務(wù)狀態(tài)可以不斷檢測，掛掉的時(shí)候，最好能夠自動重啟……

我們再來看使用平臺的價(jià)值和收益，首先持續(xù)集成的過程更加順暢，其次平臺的自動化將使運(yùn)維人員的成本降低，再次基于DevOps的理念，將使得開發(fā)和運(yùn)維在日常工作中高度協(xié)同，自動化的流程，讓一切變得規(guī)范，新版本的迭代更快更強(qiáng)，線上運(yùn)行的更加穩(wěn)定可靠。

iuap平臺支持DevOps全生命周期管理，并提供了對應(yīng)工具支撐。提供了DevOps的最佳實(shí)踐和工具使用說明，提供組件庫對研發(fā)成果進(jìn)行管理。保證編碼、構(gòu)建、測試、預(yù)發(fā)布、部署、監(jiān)控等各個(gè)環(huán)節(jié)的持續(xù)進(jìn)行。

對于快速開發(fā)，提供了一系列的開發(fā)工具、框架與組件、后端示例代碼、前端模板等。并通過官網(wǎng)文檔，進(jìn)行知識的傳遞和反饋交流，社區(qū)化的響應(yīng)開發(fā)者的各種難題。

想要解決系統(tǒng)黑盒的問題，我們通過收集瀏覽器端用戶點(diǎn)擊情況和收集Nginx日志的方式，以索引庫的方式進(jìn)行性能數(shù)據(jù)存儲，最終對大數(shù)據(jù)進(jìn)行分析，展示相應(yīng)的業(yè)務(wù)報(bào)表，可視化的查看系統(tǒng)的各項(xiàng)運(yùn)行指標(biāo)。

線上出錯(cuò)，我們通過收集服務(wù)器端應(yīng)用性能數(shù)據(jù)的方式，實(shí)時(shí)展示應(yīng)用的調(diào)用拓?fù)鋱D，并根據(jù)出現(xiàn)異常的請求，進(jìn)行下鉆，定位出具體出現(xiàn)問題的代碼。

Docker的鏡像一致性，將業(yè)務(wù)運(yùn)行所需的操作系統(tǒng)、依賴環(huán)境、業(yè)務(wù)war包等都統(tǒng)一封裝到了一起，應(yīng)用部署的時(shí)候，直接拉取鏡像即可。業(yè)務(wù)規(guī)模小的時(shí)候，只需啟動少量容器，業(yè)務(wù)規(guī)模上來后，可以執(zhí)行擴(kuò)容操作，再次拉取鏡像，以Docker的形態(tài)啟動更多的應(yīng)用容器實(shí)例。從此不再擔(dān)心大流量來襲時(shí)的束手無措。