幾年前我在一家互聯(lián)網(wǎng)公司的一個電商產(chǎn)品上工作時，經(jīng)歷了項目從無到有、業(yè)務從小到大的演變過程。當時微服務架構還沒有興起，產(chǎn)品架構主要是基于單體架構的。在一年多時間內，業(yè)務流量就擴大了十倍左右，各種功能特性需求也應接不暇。隨著業(yè)務流量和復雜性的攀升，單體架構的問題很快凸顯了出來。

首先是系統(tǒng)復雜度不斷上升。由于對業(yè)務只進行了簡單的劃分，分為兩三個大的代碼庫，所有人的代碼提交都在這兩三個代碼庫上進行，久而久之模塊之間的耦合越來越多，代碼的整潔性和可讀性都不斷下降，一個文件幾千行、一個函數(shù)幾百行的情況也屢見不鮮。一個臃腫的單體系統(tǒng)編譯、啟動、構建都會變慢，發(fā)展到后來在本地啟動主系統(tǒng)就需要5-10分鐘，可想而知開發(fā)人員在這些上面每天又會浪費多少等待時間。

其次是質量缺陷成為一大困擾。由于系統(tǒng)復雜，模塊之間耦合多，不容易寫自動化測試，在交付壓力的驅使下開發(fā)只好以滿足功能上線為第一目標，所以導致生產(chǎn)環(huán)境經(jīng)常出現(xiàn)bug，有時甚至是影響到核心功能的嚴重bug，不得不在線回滾，給公司帶來了損失之外又增添了額外的修復成本，而且也影響著團隊的上線信心。

架構的腐化也制約著創(chuàng)新的動力，團隊中有些愿意嘗試新技術、新架構的成員，但一想到如何從紛繁復雜的代碼中理出個頭緒，引入新技術的同時又不影響現(xiàn)有系統(tǒng)功能，往往就打退堂鼓了。

同時，發(fā)布的風險也在逐漸增大，當時這樣的系統(tǒng)以多實例方式部署在多個虛擬機上，自動化部署程度不高，而且生產(chǎn)環(huán)境和測試環(huán)境多少會有些不一致的現(xiàn)象。再加上前述的各種因素，導致往往在測試環(huán)境難以發(fā)現(xiàn)性能和安全方面的問題，往往在上線了以后才發(fā)現(xiàn)所發(fā)布功能存在一些問題，只好再手動回滾。發(fā)布后還需嚴密關注是否發(fā)生異常，久而久之，導致每一次發(fā)布都成為開發(fā)和運維人員的噩夢，用膽戰(zhàn)心驚形容也不為過。

而且，運維方面，由于系統(tǒng)未進行適當?shù)牟鸱?，對于水平擴展也不是那么容易，無法將系統(tǒng)中的性能瓶頸部分進行單獨擴容，就只好將整體系統(tǒng)進行擴容，浪費資源倒是其次，主要是有時有些含狀態(tài)的任務或功能無法直接擴容。

幾年后當微服務架構及其相關的持續(xù)交付、DevOps、敏捷等實踐逐步興起時，我意識到曾經(jīng)遇到過的問題不只是我們才遇到。而這些思想和方法的出現(xiàn)，正是為了解決這些問題。在我看來微服務相關的實踐實施的價值點主要有：

更簡單。如果一件事情太復雜，目標太大，就對其分解成若干個小目標，分而治之各個擊破，就會感覺容易許多。微服務正是體現(xiàn)著這樣的思想，對系統(tǒng)進行適當?shù)牟鸱?，組成一個個高內聚低耦合的模塊化服務，服務之間以輕量級通信進行交互，每個服務在獨立進程中運行，可獨立部署快速發(fā)布。無形中讓各個微服務的復雜度降低了許多，寫自動化測試也變得相對容易許多，讓團隊對開發(fā)質量和速度都能有所兼顧。

更可靠。持續(xù)構建、持續(xù)部署等開發(fā)流水線的實踐都強調盡可能用標準化和自動化的方式去完成團隊日常工作中的重復部分。這不僅僅是為了避免重復勞動，也是為了建立更加易于追蹤和控制的系統(tǒng)，提高可靠性，避免因人的手工作業(yè)疏忽所帶來的問題。

更敏捷。敏捷方法論中的核心思想之一是建立快速反饋的通路，這樣團隊才能更快地知道自己是否走在正確的道路上，及時作出調整和優(yōu)化?？窗濉I、自動化測試等實踐的目的之一都是讓團隊能夠快速而直觀地得到作業(yè)狀態(tài)和結果的反饋。小而精的微服務系統(tǒng)，也讓各項作業(yè)的執(zhí)行更加快速，從而能夠更快地得到反饋。

當然微服務架構也是一把雙刃劍，并不是每個產(chǎn)品都適合實施微服務，實施過程中也避免不了各種陣痛。但只要團隊能夠認識到微服務實施的價值所在，提前評估和控制好風險，在落地過程中發(fā)展出真正適合自己的實踐，就能發(fā)揮其作用。