企業互聯網應用高性能解決之道

本文介紹了企業互聯網開發及運維的一些實踐，深刻剖析了互聯網項目開發及上線過程當中的各類痛點及解決之道。
一個互聯網項目的上線並非那麼容易，須要通過不少的環節：從服務器的準備開始，緊接着是業務系統的搭建，搭建的過程當中涉及到操做系統、依賴中間件、應用部署、配置修改等衆多事情；搭建完畢後，進行業務的線上驗證及各類場景的演練，並進行高併發的壓力模擬測試，找出性能瓶頸，並不斷進行問題修正、架構調整；最後進行災備的演練，整理好自動化腳本，而後挑選災備環境的某一組進行上線試運行，迎接上線運行真實用戶壓力的考驗。

回想每次新項目上線的過程，每次都是一次痛苦的折磨。花費這麼長時間，根源到底是什麼？答案就是這裏面太多的環節都是依賴人工去處理。那麼咱們該如何縮短交付週期呢？

回到你們手上的互聯網項目，當項目上線後，是否是就萬事大吉了呢？慶功後，更多的事情才慢慢到來，隨着業務的開展，用戶量漸漸增長，高併發的場景也開始凸顯。因爲只是關注了業務系統自己的上線，與之相關的外圍支撐系統並無建設，這種情況下，根本沒法瞭解系統的內部運行情況。當前到底有多少用戶在訪問系統、每臺服務器正承受多大的壓力、當前的業務量究竟是多少？咱們能夠思考下，淘寶作雙11活動的時候，交易量是如何統計的？京東作618活動，實時流量又是如何統計的？咱們應該建設哪些外圍支撐，才能作到系統不是黑盒？

當線上業務系統出錯的時候，是否是常常遇到無從下手的狀況？這是由於隨着業務規模的不斷擴大，線上系統變的錯綜複雜，就像圖中的電線同樣，稍有不慎，就會起火！多是網絡問題、環境問題、代碼問題、第三方API的問題等等，想要定位問題須要各類不一樣的技術棧，調用鏈路的追蹤，沒有科學的依據，幾乎不可能。

當線上出現的問題排解的差很少了，業務也穩定了，新的問題又來了。用戶的活躍帶來了流量的井噴式暴增，稍有不慎就會致使系統崩塌。這個時候，須要進行及時的擴容，拯救系統。但每每事與願違，機器準備不到位、環境部署不夠快、業務擴容不及時，致使擴容的成本居高不下。

或者採起了自認爲「明智」的討巧作法，借用其餘業務線的機器進行了擴容，可是你的業務系統跟兄弟系統環境是不一致的。新業務的侵入，致使了其餘業務線環境的改變，反而形成了別的業務線癱瘓，真是城門失火、殃及池魚。咱們急需一致化的環境進行擴容，Docker是咱們的救兵。

面對如此多的問題，能夠想象團隊的情況會是怎樣的？團隊成天忙於救火，壓力很是大。不少時候爲了救火而救火，拆了東牆補西牆，代碼更是純粹爲了解決問題而堆上去的，代碼管理混亂，技術積累缺少……

在這種技術積累的狀況下，老闆又要開啓一條新業務線。因爲沒有統一的項目模板，致使每次項目啓動都是底層代碼都要重寫一遍。模塊封裝不夠，致使本能夠公用的模塊，每一個團隊都要從新封裝一次，研發資源的重複投入，使得研發成本居高不下。

爲了使一切更規範起來，咱們須要一個穩定的底層支撐平臺，保證業務的快速發展。作到快速開發新提出的需求，不斷的迭代小版本，開發的過程當中有一些通用的模板和通過驗證的技術組件直接套用。開發完成後，可以快速部署上線，小版本持續集成。上線之後服務不要掛掉，出現問題可以快速定位。流量暴增的時候，可以及時感知，並實現快速擴容。服務狀態能夠不斷檢測，掛掉的時候，最好可以自動重啓……

咱們再來看使用平臺的價值和收益，首先持續集成的過程更加順暢，其次平臺的自動化將使運維人員的成本下降，再次基於DevOps的理念，將使得開發和運維在平常工做中高度協同，自動化的流程，讓一切變得規範，新版本的迭代更快更強，線上運行的更加穩定可靠。

iuap平臺支持DevOps全生命週期管理，並提供了對應工具支撐。提供了DevOps的最佳實踐和工具使用說明，提供組件庫對研發成果進行管理。保證編碼、構建、測試、預發佈、部署、監控等各個環節的持續進行。

對於快速開發，提供了一系列的開發工具、框架與組件、後端示例代碼、前端模板等。並經過官網文檔，進行知識的傳遞和反饋交流，社區化的響應開發者的各類難題。

想要解決系統黑盒的問題，咱們經過收集瀏覽器端用戶點擊狀況和收集Nginx日誌的方式，以索引庫的方式進行性能數據存儲，最終對大數據進行分析，展現相應的業務報表，可視化的查看系統的各項運行指標。

線上出錯，咱們經過收集服務器端應用性能數據的方式，實時展現應用的調用拓撲圖，並根據出現異常的請求，進行下鑽，定位出具體出現問題的代碼。

Docker的鏡像一致性，將業務運行所需的操做系統、依賴環境、業務war包等都統一封裝到了一塊兒，應用部署的時候，直接拉取鏡像便可。業務規模小的時候，只需啓動少許容器，業務規模上來後，能夠執行擴容操做，再次拉取鏡像，以Docker的形態啓動更多的應用容器實例。今後再也不擔憂大流量來襲時的束手無措。