為什麼演進式架構被譽為最好的系統迭代模式？
關注ITValue，檢視企業級市場最新鮮、最具價值的報道！
圖片來源@視覺中國
數字化轉型已經成為傳統企業的必然選擇。隨之而來的業務場景、使用者習慣和行為在迅速變化，許多傳統行業線上業務出現急速增長。
金融行業的移動支付、網際網路理財等，汽車製造行業的營銷、電商、售後服務等線上業務比例迅速提高。IT團隊業務開發、迭代都以每月、甚至每週來計，需要7*24小時響應，這些給系統開發和運維帶來極大挑戰。
傳統行業對於IT效率的變革需求以及業務模式的創新導致系統更新頻繁，應用複雜度也急劇上升，傳統架構不堪重負。因此，架構轉型成為了一些企業數字化過程中的最大難點。
通過對雪浪大會200多家制造企業的痛點調研顯示，在系統支撐方面，排在前四的難題分別為：系統複雜性越來越高、運維管理複雜度高；打造一支全棧運維團隊困難；線上訪問壓力大；裝置採購維護成本高。
ThoughtWorks是一家技術類諮詢公司。這家公司長期致力於從全球不同的區域，服務於不同的客戶，在不同的業務模式下面做不同的專案。成功的案例包括德國戴姆勒公司的營銷、電商、售後服務如何由消費者主導實現數字化線上、美國視訊網站Netflix的系統架構演進式發展等。
通過全球專案經驗的積累和實踐， ThoughtWorks總監級諮詢師Neal Ford提出演進式架構的概念，將“可演進性”作為新的架構特徵加入到系統中，讓它在系統演進時為其他特徵（比如上文提到的業務需求、效能、安全性、可擴充套件性等）提供保護。這便是演進式架構，它使我們可以兼顧多個架構維度進行引導式的增量變更。
不久前，Neal Ford帶著新書《Building EvolutionaryArchitectures: Support Constant Change》來到中國進行宣講。鈦媒體記者藉此機會與Neal Ford進行了深度交流，為企業傳統架構的迭代升級提供一種新的思考方式。
NealFord帶著新書《Building Evolutionary Architectures: Support Constant Change》以及他的新的Idea“演進式架構”在QCon大會演講
01
在不破壞原有IT架構的前提下進行“演進”在傳統企業軟體開發流程中，經常需要面臨改動，有來自使用者需求的改動，有來自市場的改動以及為了一些潛在機會而產生的改動等。
這些改動要求企業能夠快速做出調整。但不幸的是，事情並不總是如我們所願。
這是因為企業的業務應用經過多年IT建設，系統非常龐大，難以更改。例如企業傳統SAP、汽車製造企業裡傳統DMS以及MES等，要改動其中任何一小部分，都需要重新部署整個應用。敏捷開發和快速交付更無從談起。
另外，傳統企業在長期的IT建設過程中，通常大量使用外包團隊，這導致採用的技術棧之間差異較大，統一管控和運維要求更高。需要運維7*24小時全天候值守、線上升級，並快速響應。
而在此時脫穎而出的微服務架構，讓傳統企業眼前一亮，它具備諸多優勢，例如獨立開發、獨立部署、獨立釋出，去中心化管理，支援高併發高可用，支援豐富技術棧，企業可以根據需要靈活技術選型。
NealFord認為，微服務是支援演進行為的眾多架構之一。“微服務是後DevOps革命時代出現的第一種全新架構風格。它是第一個全面擁抱持續交付的工程實踐，也是演進式架構家族的一員。演進式架構以支援增量的、非破壞的變更作為第一原則，同時支援在應用程式結構層面的多維度變化。不過，微服務僅僅是支援某些演進行為的眾多架構之一。”
而演進式架構則在微服務架構基礎上增加了兩點思考——既要滿足企業應用的真實場景，還要符合技術的演進。
首先，建立演進式架構，應當滿足企業應用的真實場景。
這也回答了我們文章的問題——為什麼演進式架構被譽為最好的迭代模式？因為這種架構不會破壞原有傳統軟體包，而是將傳統IT架構演進到微服務架構上。
NealFord在《演進式架構》中也提到，“對於一個大的軟體包，一個大的單體的應用，如果做微服務轉型，肯定不是把這個大的單體應用直接幹掉不要，建一個新的微服務平臺出來，而更傾向於一種做法，即我怎麼能夠從SAP、DMS這樣一個傳統軟體包的模式， 一步步的把它演進到一個微服務架構上，這是演進式架構要解決的一個重要問題”。
原本對傳統企業來講，SAP、DMS以及MES這類傳統軟體包等本身是封閉的，企業購買這樣的軟體包最大的一個出發點是來降低自己的IT成本去實現IT能力。但是在數字化轉型的大趨勢下，創新又成為企業最主要的訴求。
ThoughtWorks從技術的角度出發，認為更應該照顧企業真實的應用場景，定製化地開發軟體，或者說，從定製化的軟體平臺下開發出獨特的業務模型。
同時，演進式架構符合技術的演進。
NealFord認為，微服務本身是一種架構的模式或者是一種架構的風格，而這種架構風格正好是演進式架構的一些原則和實踐的最佳體現。“比如業界經常做微服務轉型的時候會說，微服務本身的力度或者微服務本身的範圍應該是什麼樣的，而我認為演進式架構可以幫助企業將一個微服務的架構在力度的層面、在整個架構體系上能夠不斷地去演進。”
NealFord向鈦媒體表示，這種技術演進方向有兩個：
“第一個方向是這種增量式的演進，讓系統能夠做到增量式的演進或者增量式的變更，而這本身作為演進式架構定義中的第一個維度，它是天生要解決這個問題。
第二個方向，它叫做指引式的演進或者嚮導式的演進，嚮導式的演進就是說我在一個系統裡面希望能夠提升它的效能，我怎麼能向著我們想要的效能方面去演進，所以它定義了一個適應度函式（fitness function），通過適應度函式可以幫助我們的架構的開發人員明確地認知我現在想要的這個方向是不是我現在架構所演進的方向，是不是我想要的方向，然後它可量化地告訴我的開發者，我離現在這個目標到底還有多遠，它是這樣一種模式。所以面對企業不斷增加的應用需求，它天生可以解決企業增量式、迭代式開發的一種訴求。”
然而，微服務也不可避免地表現出它的劣勢——它會帶來系統的各種複雜度、運維要求更高等諸多難點。對於團隊來說，搭建微服務架構上手難，運維效率低，運維成本高。
另外，建立微服務還可能帶來團隊之間溝通上的衝突——微服務需要與DevOps（Development&Operations）同步推進。當微服務被分割成一個個獨立的業務模組後，服務間通訊介面設計非常重要。如何科學地將系統部署到伺服器上，保證各個服務高效執行，更是難點。
02
演進式架構符合傳統企業轉型需求“當我們談演進式架構的時候，其實是有很多不同的原則。這些原則都很嚴格，而微服務某種程度上展現出了一些演進式架構的原則。例如我們在談微服務的時候，主要是想用它來快速應對頻繁的需求變更，因此微服務所承載的期望便是讓我們能儘可能快的適應變化，演進式架構中所倡導的進化性與此不謀而合。”
NealFord補充道，關於可進化性存在一個理解誤區——開發者要非常聰明的想到所有可能出現的變化，並且為所有的這些可能的變化寫好程式碼，哪怕到頭來根本就沒變。但其實，可進化性並不同於可維護性，“不是說要怎麼預測未來，而是一種隨時準備響應變化的狀態，而不管你是否提前就設想好了這些變化。”
在今天來看，其實演進式架構本身是有一定基礎的，當企業想採用演進式架構這種模式的時候，需要以敏捷的開發模型、敏捷的開發方式、持續交付的開發基礎設施或者是持續交付的開發實踐以及DevOps的實踐來作為整個架構的基礎。如果企業沒有這樣的基礎，實際上是很難做到演進式架構的，而演進式架構本身它也是要求在整個企業開發的流程和模型上需要敏捷、持續交付，要去做DevOps。
據Neal Ford介紹，目前在業界採用演進式架構企業不僅有美國視訊網站Netflix公司，還有很多ThoughtWorks參與或者是合作的公司都在採用演進式架構中的一些實踐。只不過在這之前並沒有把它定義成演進式架構或者是適應度函式，而是把它定義成fitness function。
而在這些傳統企業中，很多企業是通過持續交付流水線，通過對於架構、對於測試體系的一些追求，對於架構本身的轉型，一直在實踐著演進式架構的模式。因為它們恰恰滿足了演進式架構的一些特點，例如：
第一是模組化和耦合。邊界劃分明確的元件，顯然可以給希望做出非破壞性變更的開發人員以更大的便利。而毫無架構元素的混亂架構就無法做到演進式變更，因為它缺少模組化。另外不適當的耦合將變更導向難以預料的方向，從而阻礙演化。而演進式架構都支援一定程度的模組化，這種模組化通常體現在技術架構層面（例如經典的分層架構）。
第二是圍繞業務能力組織。現在越來越多的成功架構都以在領域架構層的模組化為特色。基於服務的架構與傳統的SOA主要區別在於模組劃分的策略，SOA是嚴格按照技術層進行模組劃分，而基於服務的架構則傾向於按業務領域劃分。
第三是試驗。試驗是演進式架構給商業交付帶來的最大價值之一。從操作角度來講，可以採用A/B測試等常見的持續交付實踐對應用進行低成本的、微小的變更。微服務架構常常是圍繞服務之間的路由來定義應用程式的。通常微服務架構圍繞服務之間的路由來定義應用程式，允許同一個服務的多個版本同時執行。這反過來也使得試驗和現有功能的逐步替換成為可能。最終，這使得企業業務可以花更少的時間去猜測待辦故事項，從而投入到假設驅動開發中。
而在國內，通過鈦媒體記者近期的走訪發現，大部分傳統企業架構還不能實現敏捷開發、持續交付等，要實現數字化轉型，首先就需要對企業傳統架構做轉型。
NealFord表示，對於企業傳統架構的轉型，首先要把企業自己基礎的工程實踐能夠搭建起來，使原來採購軟體包的模式能夠向新的模式做轉型。
“比如說在持續交付層面，如果一個企業不是在做持續交付的轉型，那企業在做精益企業（或數字化）轉型的時候，第一步要做的事情就是要有一個持續整合的轉型，把自動化的基礎設施能夠搭起來。這是基礎能力，不僅僅是向演進式架構轉變，更企業在做數字化轉型時必備的一些能力。”
03
大資料、AI技術都將被引入演進式架構“目前在演進式架構中已經引入了很多AI的實踐，比如說在一些企業裡面會用TensorFlow去寫一個框架，幫助他去分析在網路傳輸這一層裡面，從安全的角度是不是有一些模式可以被快速地發現，有一些安全的點或者是有一些安全的攻擊的行為是不是可以從網路傳輸這一層來用AI來做分析和發現。它也希望未來可以通過把目前AI技術應用所處的層面逐漸往上提，提到不同服務之間傳輸資訊的層面上、是不是可以利用AI找到這樣的模式，能夠幫助我們企業識別出來我的安全風險。”
Neal Ford認為，在當下最時髦的AI技術，在未來可能會被更多地引入演進式架構中，加入到整個企業架構適應度函式的設計，或者是在架構演進的過程中利用AI的能力做更多的事情。
“同樣對於大資料大資料或者是資料型的專案，演進式架構中可以應用在一些場景中。比如說演進式架構裡面去定義企業最關注的適應度函式、最關注的架構設計要素。而每一個要素都可以通過適應度函式把它定義下來，我認為每個架構應該有自己非常獨特的或者是特定的適應度函式，或者是這種架構規則的新的定義，就好像我們寫unittest和寫functional test是一樣的。因為你是根據某一個專案去寫的，而不會把這個專案的規則直接搬到另一個專案上去。”
無論是傳統架構還是演進式架構，系統本身在市場上是有競爭者的。Neal Ford也坦率地說，如果是利用這個系統直接去賺錢的企業或者是組織，這樣的企業會首先採用演進式架構的模式。而往往一個企業當它先開始採用演進式架構這種模式的時候，這種架構一開始對企業的影響並沒有那麼大。“只是簡單的在企業流水線上佈一個適應度函式或者是佈一個架構檢查的指令碼，其實就已經在採用演進式架構當中的實踐了，但是顯然這種實踐對於人和組織來講並沒有什麼太大的改變。”
“但是如果企業想充分發揮演進式架構帶來的好處，那對於整個團隊的組織結構肯定是要發生一些變化。比如說企業的組織結構應該能夠更好地支撐業務的敏捷性轉型、企業的組織結構應該更好地降低我在團隊不同成員之間的波動，我能夠讓團隊是一個相對比較穩定的團隊。同時我的團隊能夠支撐DevOps這樣一些實踐的追求或者應用。”
這就像1967年康威提出的“康威定律”， 企業需要關注怎麼組織團隊結構，以及不同的團隊結構可能影響到最終的系統形態。只有團隊對服務有很好的所有權意識，團隊做出來的微服務才是這種鬆耦合的獨立服務。康威定律在1967年被提出來，但是真正被業界採納其實是在近幾年有了微服務以後，團隊才開始採用康威定律。“所以說這件事情相對來看會有一個比較長的週期。其實在業界已經有了這樣一些原則在那裡了，但是真正的被企業界所應用還是需要一定時間的。“Neal Ford表示。
2018年8月10日，在由ITValue舉辦的年度三亞IT價值峰會上，ThoughtWorks高管還會分享更多關於系統架構的主題內容，敬請期待！
一場“悅後即焚”的CIO閉門交流會
遍佈企業級“尖貨”的黑科技市集
拿獎拿到手軟的十週年慶典晚宴
以及廣受歡迎的德州撲克大賽、迎賓紅酒會、痛點沙龍
……
地點：三亞藍灣綠城威斯汀度假酒店
中國最大的技術高管實名社群，提供網際網路時代最全面權威、也最前沿有趣的B2B市場資訊解讀。
點選www.itvalue.com.cn，進入ITValue社群，與CIO們一起腦力激盪！
我們只提供有價值的乾貨！
長按二維碼
關注ITValue