本文為《持續演進的Cloud Native：雲原生架構下微服務最佳實踐》 一書序文。作者從全局視角出發，全面闡釋Cloud Native 的關鍵技術，以及其衍生出來的工具、團隊文化等核心要素，對於正在部署微服務架構或開展雲原生業務的企業和組織而言，終於有了面向落地的務實參考和全面指導。
01 架構沒有絕對的對與錯
在技術的領域裡，並不存在“上帝”。沒有人的每句話都是對的，沒有人的所有思想都能被別人所接受。
我經常在公司範圍內培訓，首先是灌輸架構思想和解決方案，然後會在實戰演練中模擬一個比較簡單的業務場景，把所有人分成 4 個團隊，每個團隊大概有 10 個人。結果發現，每個團隊最終形成的架構圖總有很大差異，很難評價一個團隊的做法是對是錯。例如，是要拆分為 3 個服務，還是 5 個服務，他們有各自的理由，除非比較明顯的問題，否則你很難以一個理由去否定另一個理由。原因只是各個團隊站在了不同的維度綜合判斷、權衡，形成了自己認為滿意的架構方案。因此，架構沒有絕對的對與錯，只是在不同的角度做出的決定而已。
02 架構很難被衡量
每個公司的管理層都希望儘可能地去衡量架構的先進性，希望認清差距，向著好的架構方向不斷演進。然而架構很難被衡量，須同時具備差距特別明顯、制定指標的人能力達到一定高度、業務場景比較接近這三條才有可能衡量。當然我們可以去制定一些指標，這些指標應該是參考性的，作為一個自檢項，而不是評價標準。從這個角度看，並不是符合Cloud Native 就是好的，不符合就是差的，當不符合時，你的理由是什麼？你站在問題的哪個角度？
Martin Fowler 曾說：“優秀的技術人員的觀點勝過任何度量，儘管它是主觀的。”因為你無法統一每個人關注的點，以及對各自關注的點的重視程度，所以架構很難被衡量。
03 架構需要持續演進
在傳統企業中，架構設計是一個很重要且很耗費時間的過程，需要經過很多輪審核，架構文檔動輒幾百頁，而且這個文檔絕對不能有沒考慮到的問題，必須面面俱到、接近完美。例如，目前系統還沒有用戶，就要為未來 1 千萬的用戶耗費精力解決性能問題，而且軟件永遠有你想象不到的問題發生。實際上我們描述的是一種靜止的架構，這種架構每次變更都需要耗費巨大的成本。如果此時恰好出現了一個基於敏捷思想的競爭對手，則會形成一種鮮明的對比，他們不去考慮太長時間之後的事，出現什麼問題就解決什麼問題，因為有可能一年以後這個項目死了，也有可能用戶人數突破 1 億，系統需要進行大規模重構。
總之，未來是不確定的。可見，架構是錘鍊出來的，而不僅是設計出來的。
反應速度是傳統企業的硬傷，這不是通過加班就能解決的。可以看一下互聯網巨頭們每年的發佈次數，動輒每年發佈幾百萬乃至上千萬次，每個服務每天都在發生變化，每週可能都會上線。在如今這個快速發展的世界裡，你無法依賴一個人去做所有的決策。這就需要發揮所有成員的主觀能動性，也就是說，架構應該交給一線決策。回到前面提到的問題，服務怎麼拆分更好？我想只有深入瞭解需求、場景、目標甚至自身條件之後才能做出決策。並且，架構的演進不是一蹴而就的，而是一個長期發展的過程。
04 變革需要堅決
歷史上的變革大多阻力重重，因為一旦變革就意味著打破原有的“默契”，打破原有的“潛規則”，而“頑固派”通常是原有文化的受益者，他們通常不會反對變革，而是通過“我們不能完全照抄，要走出適合我們的路”來促成妥協。如果變革過程中遇到任何風吹草動，就更會給“頑固派”各種理由“走自己的路”。這也就是為什麼我們熟知世界領先 IT 企業的技術、研發流程和企業文化，而就是學不會的原因。
這時候需要的是企業領導者的果斷、堅決。只要方向沒錯，就要堅持，決不動搖。下面這段話是馬雲對劉振飛（阿里技術保障部負責人）關於阿里雲內部爭議的回覆，反映了一個領導者在企業變革過程中起到的作用。
在王堅加入阿里之前，我跟教授（指曾鳴）討論公司的未來，覺得雲計算和大數據代表未來，對國家和社會的發展有長遠的意義，所以我們要幹，這是第一點。但是怎麼做雲計算、大數據？我們誰也不知道。現在來了個人叫王堅，他說：“我知道怎麼做”，為什麼不支持呢？這是第二點。第三點，即使萬一做失敗了，那也沒關係，咱們的人倒下 70%，還有 30%活著，咱們活下來的人打掃戰場，換個方向繼續幹，總要把它做出來。
05 寫代碼不同於搬磚
如果是搬磚，那麼效率高的人和效率低的人之間的差距不會太大，因此每個人每天的工資都是相對固定的。但是在如今這個知識爆炸的時代，對於從事軟件行業的群體來說，效率高者的工作效率比效率低者的可能高出幾十倍、幾百倍，優秀的人能寫出更高質量的代碼，能夠預測問題。而在這個行業越是優秀的人才越是稀缺，因此很多互聯網公司都願意花大價錢去招一些更優秀的人。
優秀的人不願意來，不一定是因為錢。花錢僱傭優秀的人是一方面，怎樣管理這些人又是另外一方面，用管理搬磚者的方式來管理他們是不行的，管理優秀的人需要給予他們更多的信任，需要營造一種公開透明、自由高效的環境。
06 關於《持續演進的Cloud Native》
為什麼會出現 Cloud Native 這個概念呢？無論是雲化、平臺化，還是微服務架構，又或者是敏捷開發、自動化，都只是描述了幾個點，而 Cloud Native 更像是一個面，通過它把這些點都關聯起來了。某幾個點做得很好而忽略了其他點通常會走入誤區。例如，某些團隊只關注服務拆分，而忽略了工具、組織對微服務的影響，最終效果並不理想。又如，要提升系統的可用性，只是從技術的角度去考慮是不夠的，還要考慮如何通過自動化測試提升可用性，如何通過 Code Review 提升可用性，以及當故障發生時如何快速修復。我希望通過個人的工作經歷以書的方式傳遞一些這方面的經驗教訓。
本書分別從架構、研發流程、團隊文化三個角度全面論述 Cloud Native，因為只有三方面配合才能達到理想的效果。我見到過無數失敗的案例，絕大多數都是因為考慮得比較片面，例如單純從架構角度進行變革，或者單純從研發流程角度變革。我們希望模仿Google、Facebook、Amazon、Netflix 等領先企業，但是往往高估了架構的影響力，而低估了研發流程和團隊文化的影響力。實際上，研發流程和團隊文化對架構有著非常重要的影響。本書以 Cloud Native 的起源、訴求及組成開始，全面描述了 Cloud Native 的各個方面。從架構角度闡述瞭如何實施微服務架構，如何構建敏捷基礎設施及平臺服務。同時，從可用性、可擴展性、性能、一致性等角度描述了微服務架構中產生的問題及解決方案。最後，分別描述了 Cloud Native 下的研發流程和團隊文化。
本書比較適合技術管理者、架構師和有一定基礎的技術人員閱讀，特別是傳統軟件企業的技術領導者，以及希望向互聯網公司轉型的或者轉型失敗的企業技術領導者。此書將幫助這些人少走彎路。還有一些比較有經驗的高級研發人員，閱讀此書也利於系統掌握Cloud Native 的關鍵技能。無論如何，都希望此書能給你帶來較好的體驗，使你獲得啟發。
《持續演進的Cloud Native：雲原生架構下微服務最佳實踐》，作者王啟軍，電子工業出版社11月出版。瞭解詳情請點擊擴展鏈接。
閱讀更多 博文視點Broadview 的文章
