資深首席架構師眼中的架構應該是怎樣的?

来源:http://www.cnblogs.com/agileai/archive/2016/04/14/5390691.html
-Advertisement-
Play Games

“架構的視角每個人都不一樣,這位在eBay、攜程、唯品會等平臺型互聯網公司都工作過的老司機就以平臺架構視角和大家分享架構心得體會。一家之言,歡迎討論。 本文首發於InfoQ垂直公眾號「聊聊架構」,ID:archtime。 我對架構定義的理解 大概在7~8年前,我曾經有一個美國對口的架構師導師,他對我 ...


“架構的視角每個人都不一樣,這位在eBay、攜程、唯品會等平臺型互聯網公司都工作過的老司機就以平臺架構視角和大家分享架構心得體會。一家之言,歡迎討論。

本文首發於InfoQ垂直公眾號「聊聊架構」,ID:archtime。

我對架構定義的理解

大概在7~8年前,我曾經有一個美國對口的架構師導師,他對我講架構其實是發現利益相關者(stakeholder),然後解決他們的關註點(concerns),後來我讀到一本書《軟體系統架構:使用視點和視角與利益相關者合作》,裡面提到的理念也是這樣說:系統架構的目標是解決利益相關者的關註點。

這是從那本書裡頭的一張截圖,我之前公司分享架構定義常常用這張圖,架構是這樣定義的:

  1. 每個系統都有一個架構

  2. 架構由架構元素以及相互之間的關係構成

  3. 系統是為了滿足利益相關者(stakeholder)的需求而構建的

  4. 利益相關者都有自己的關註點(concerns)

  5. 架構由架構文檔描述

  6. 架構文檔描述了一系列的架構視角

  7. 每個視角都解決並且對應到利益相關者的關註點。

架構系統前,架構師的首要任務是盡最大可能找出所有利益相關者,業務方,產品經理,客戶/用戶,開發經理,工程師,項目經理,測試人員,運維人員,產品運營人員等等都有可能是利益相關者,架構師要充分和利益相關者溝通,深入理解他們的關註點和痛點,並出架構解決這些關註點。

架構師常犯錯誤是漏掉重要的利益相關者,溝通不充分,都會造成架構有欠缺,不能滿足利益相關者的需求。利益相關者的關註點是有可能衝突的,比如管理層(可管理性)vs技術方(性能),業務方(多快好省)vs 技術方(可靠穩定),這需要架構師去靈活平衡,如何平衡體現了架構師的水平和價值。

關於架構的第二點定義是說架構主要關註非功能性需求(non-functional requirements),即所謂的-abilities。

這個是我上次公司內分享的一個圖。

這個是slideshare一個ppt裡頭截取的,兩個圖都是列出了架構的非功能性關註點;關於架構的水平該如何衡量,去年我看到一句話,對我影響很大。

Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.

翻譯為中文就是,架構表示對一個系統的成型起關鍵作用的設計決策,架構定系統基本就成型了,這裡的關鍵性可以由變化的成本來決定。這句話是Grady Booch說的,他是UML的創始人之一。

進一步展開講,架構的目標是用於管理複雜性、易變性和不確定性,以確保在長期的系統演化過程中,一部分架構的變化不會對架構的其它部分產生不必要的負面影響。這樣做可以確保業務和研發效率的敏捷,讓應用的易變部分能夠頻繁地變化,對應用的其它部分的影響儘可能的小。

我剛入軟體開發這個行業之初,談的架構主要是性能,高可用等等。現在,見過無數遺留系統,特別是國內企業IT的現狀,無數高耦合的遺留系統,不良的架構像手銬一樣牢牢地限制住業務,升級替換成本非常巨大, 所以我更加關註可理解,可維護性,可擴展性,成本 。我想補充一句,創業公司創業之初獲得好的架構師或技術CTO非常重要。

架構的迭代和演化性

我是屬於老一代的架構師,99年參加工作。職業初學了很多RUP,統一軟體過程的理念。RUP的理念對我的架構有很深的影響,RUP總結起來就是三個特點:

  1. 用例和風險驅動Use Case and risk driven

  2. 架構中心Architecture centric

  3. 迭代和增量Iterative and incremental

RUP很註重架構,提倡以架構和風險驅動,項目開始一定要做端到端的原型(prototype);通過壓測驗證架構可行性,然後在原型基礎上持續迭代和增量式開發,開發->測試->調整架構->開發,迴圈,如下圖所示:

從上圖可以看出架構師要儘可能寫代碼,做測試,紙上談兵式做架構而後丟給團隊的作法非常不靠譜(除非是已經非常清晰成熟的領域)。另外,做技術架構的都有點完美主義傾向,一開始往往喜歡求大求全,忽視架構的演化和迭代性,這種傾向易造產品和用戶之間不能形成有效快速的反饋,產品不滿足最終用戶需求,繼續看下麵兩個圖:

第一個圖是講最小可用產品(Minimum Viable Product, MVP)理念,做出最小可用產品,儘快丟給用戶試用,快速獲取客戶反饋,在此基礎上不斷迭代和演化架構和產品。

第二個圖是過度工程(Over Engineering)的問題,其實也是講產品架構和用戶之間沒有形成有效的反饋閉環,架構師想的和客戶想的不在一個方向上,通過最小可用產品,快速迭代反饋的策略,可以避免這種問題。

註意,在系統真正地投入生產使用之前,再好的架構都只是假設,產品越晚被使用者使用,失敗的成本和風險就越高,而小步行進,通過MVP快速實驗,獲取客戶反饋,迭代演化產品,能有效地減少失敗的成本和風險。

另外,多年的經驗告訴我,架構,平臺不是買來的,也不是用一個開源就能獲得的,也不是設計出來,而是長期演化才能落地生根的。

構建閉環反饋架構

先分享一個鏈接,這幾年對我架構影響最深的一篇文章。這篇文章是關於DevOps的,但對系統架構同樣適用:

  • http://itrevolution.com/the-three-ways-principles-underpinning-devops/ 

這篇文章講述了企業通向DevOps的三條必經之路,我們來看看這三條道路對架構師的啟示。

第一條道路,系統思維,開發驅動的組織機體,其能力不是製作軟體,而是持續的交付客戶價值,架構師需要有全局視角和系統思維(System Thinking),深入理解整個價值交付鏈,從業務需求、研發、測試、集成,到部署運維,這條價值鏈的效率並不依賴於單個或者幾個環節,局部優化的結果往往是全局受損,架構師要站在系統高度去優化整個價值交付鏈,讓企業和客戶之間形成快速和高效的價值傳遞。

第二條道路,強化反饋環,任何過程改進的目標都是加強和縮短反饋環。剛入行的工程師,也是中國學生的普遍問題,就是生產運維意識不足(監控是系統反饋的重要環節)。有兩句話是這樣講的:

  1. no measurement, no improvement沒有測量,就沒有改進和提升

  2. What your measure is what you get你測量什麼,就得到什麼

沒有監控或者監控不完善的系統相當於裸奔,開車上高速無儀錶盤。有一篇很不錯的關於測量驅動開發的文章,在InfoQ上的,向大家推薦:

  • http://www.infoq.com/cn/articles/metrics-driven-development

這篇文章提出了度量驅動開發的理念,即所謂MDD,在系統,應用和業務三個層次,通過三級監控,構建三個反饋環,在監控測量基礎上持續改進系統和架構,我最近也在參考這個理念設計一個電商平臺的技術架構,見下圖:

這是一個電商平臺的架構,整個體現了閉環架構的思想,右側是整個平臺的反饋監控環節。具體如下:

  1. 系統層監控計算網路存儲,構建系統層的反饋環

  2. 應用服務層,監控業務、應用、服務,甚至整個研發流程,構建應用和服務層的反饋環

  3. 客戶體驗層,監控端用戶和分析網站用戶的行為,構建和客戶的反饋環

下麵這個圖展示了系統提升和改進的一般方法:

收集->測量->調整->閉環重覆,在有測量數據和反饋的基礎上,系統、應用、流程和客戶體驗才有可能獲得持續的提升和改善,否則沒有數據的所謂改進只能靠拍腦袋或者說猜測。

第三條道路,鼓勵勇於承擔責任,冒險試錯和持續提升的文化。這點是最難的,一般和企業人才密度有關。工具,技術,流程只是一個公司的冰山浮出水面的部分,而真正對企業效能影響大的則是冰山水下的部分,即企業的人和文化,架構師作為技術和架構的佈道者,有責任義務鼓勵和推動試錯文化。

架構師要深入領會這三條道路,關註整個價值交付鏈的效率,關註每個環節的閉環反饋,鼓勵和推動公司的試錯文化,打造全系統的閉環架構(Architecting for closed loop feedback),提升整個系統效能。下圖的DevOps和每日交付是每一個互聯網系統架構師的夢想和努力的方向。

談談微服務架構

微服務我想大家都聽得很多了,我本人也非常關註和推崇微服務,從技術角度講,我認為微服務主要體現的是單一職責和關註分離的思想,從單進程模塊化進一步拓展到跨進程分散式的模塊化。微服務是獨立的開發、測試、部署和升級單元,正如我在第一點架構定義中提到的,微服務中每個服務可以獨立演變,它的cost of change比較小,整體架構比較靈活,是一種支持創新的演化式架構。

去年MartinFowler寫了兩篇文章,給微服務潑冷水的,建議大家好好讀下。

  1. http://martinfowler.com/bliki/MicroservicePrerequisites.html

  2. http://martinfowler.com/bliki/MicroservicePremium.html

這個圖講什麼時候該引入微服務。微服務有額外成本的,需要搭建框架、發佈、監控等基礎設施。初創和小規模團隊不建議採用。主要決定是因素系統複雜性和團隊規模,當到達一個點,單塊架構嚴重影響效率才考慮 。另外補充一點,微服務更多是關於組織和團隊,而不是技術。

架構和組織文化關係

再談一下康威定律

Conway’s law: Organizations which design systems[...] are constrained to produce designs which are copies of the communication structures of these organizations.
(設計系統的組織,其產生的設計和架構等價於組織間的溝通結構。 )

從單塊架構到微服務架構是這個定律的很好體現。

團隊是分散式的,系統架構是單塊的,開發,測試,部署協調溝通成本大,嚴重影響效率,嚴重時團隊之間還容易起衝突。

將單塊架構解耦成微服務,每個團隊開發,測試和發佈自己負責的微服務,互不幹擾,系統效率得到提升。

可見,組織和系統架構之間有一個映射關係(1 ~ 1 mapping),兩者不對齊就會出各種各樣的問題,一方面,如果你的組織結構和文化結構不支持,你也無法成功建立高效的系統架構,例如集中式和嚴格職能(業務, Dev, QA, Deployment, Ops)的企業,很難推行微服務和DevOps,推行Docker/PaaS平臺也會比較困難,這樣的組織職能之間都傾向於局部優化(local optimization),無法形成有效的合作和閉環。

反過來也是成立的,如果你的系統設計或者架構不支持,那麼你就無法成功建立一個有效的組織;作為系統架構師,一定要深入領會康威定律,設計系統架構之前,先看清組織結構,也要看組織文化(民主合作式,集權式,叢林法則式,人才密度),再根據情況調整系統架構或者組織架構。

架構師心態和軟技能

空杯,或者說開放心態(open minded)是一個成熟架構師的應有心態,stay hungry, stay foolish, 心態有多開放,視野就有多開闊。來自《高效能人士的七個習慣~史蒂芬~柯維》的一句話送給每一個架構師 :

如果一位具有相當聰明才智的人跟我意見不同,那麼對方的主張必有我尚未體會的奧秘,值得加以瞭解。與人合作最重要的是,重視不同個體的不同心理、情緒與智能,以及個人眼中所見的不同世界。與所見略同的人溝通,益處不大,要有分歧才有收穫。

另外再推薦一個本書《軟體架構師的12項修煉》,這書中三個觀點很值得每個架構師學習領會:

  1. soft skills are always hard than hard skills,軟技能比硬技能難

  2. choosing relationship over correctness ,註重關係重於誰對誰錯

  3. 架構的政治性,在中大型公司里工作的架構師尤其要學習

政治指的是和他人協作將事情搞定的藝術,架構是一種社交活動,在技術的世界里,個人主義很容易被打敗,即使你的目的是好的技術是最優的,技術決策是政治決策(technical decisions are political decisions),一個技術產品,一波人可以做,另一波人也可以做,到底誰做的好,真不好說,不管誰做,都給業務套上了一副手銬。

架構師如何提升?實戰,實戰,實戰!規劃職業,找好的團隊和項目,總結分享,學習GitHub開源項目,儘可能參與和開創自己的開源項目和產品,並長期積累。

我對一些架構師爭議主題的看法

主要爭議是兩個話題:

  1. 技術和業務的關係。

  2. 架構師要寫代碼嗎?

架構師怎麼回答這類問題?一個成熟架構師的口頭禪:視情況而定,不一定,是也不是,it depends。技術和業務,架構師要理解業務嗎?看產品和客戶,如果是業務性產品,肯定要理解業務,如果是技術型產品,就不一定。

架構師要寫代碼?也不一定,個人覺得儘可能要寫,如果你寫過十年以上代碼了,每年不少於2萬行,都玩通了,可以不寫。另外架構師如果寫代碼,要把控度,不要一頭鑽入代碼,花大量時間解決細節和複雜性問題,忽視全局和系統性問題。

最後

我想說中國現在的互聯網發展趨勢很好,越來越多的人加入架構師這個行業,這個行業正在“萬物生長”。 但是我們現在還沒有馬丁福勒,adrian cockcroft這樣的架構牛人物,我輩需不斷努力,期待中國10~20年後出現超過十個馬丁福勒,adrian cockcroft這樣的大牛神級人物。我們必不可停止探索,而一切探索的盡頭,就是重回起點,並對起點有首次般的認識。

老司機介紹

楊波,具有超過10年的互聯網分散式系統研發和架構經驗,曾先後就職於:eBay中國研發中心(eBay CDC),任資深研發工程師,參與億貝開放API平臺研發,攜程旅游網(Ctrip),任技術研發總監,主導攜程大規模SOA體系建設,唯品會(VIPShop),任資深雲平臺架構師,負責容器PaaS平臺的調研和架構,目前就職於法國LVMH集團中國區的垂直電商部門,任職電商首席架構師,幫助傳統IT向互聯網轉型。

本文為轉載文章,如有侵權請聯繫公眾號:數通暢聯或QQ群:299719834,將第一時間刪除處理。


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 前言:調試技巧,在任何一項技術研發中都可謂是必不可少的技能。掌握各種調試技巧,必定能在工作中起到事半功倍的效果。譬如,快速定位問題、降低故障概率、幫助分析邏輯錯誤等等。而在互聯網前端開發越來越重要的今天,如何在前端開發中降低開發成本,提升工作效率,掌握前端開發調試技巧尤為重要。 本文將一一講解各種前 ...
  • 因為之前一直有人給我推薦gulp,說他這裡好哪裡好的。實際上對我來說夠用就行。grunt熟悉以後實際上他的配置也不難,說到效率的話如果真是要完整打包上線也不在乎那麼幾秒時間,對於項目來說線上效率關鍵,但是線下效率只要不是讓人無法忍受頁沒有太多問題。不過不管怎麼說,需要親自用過gulp之後才能品評他和 ...
  • jquery deferred對象就是jQuery的回調函數解決方案,它解決瞭如何處理耗時操作的問題,對那些操作提供了更好的控制,以及統一的編程介面,本文章向碼農們介紹jQuery deferred對象。 一、什麼是deferred對象? 開髮網站的過程中,我們經常遇到某些耗時很長的javascri ...
  • 這是用戶利用do_Gridview和do_ListView及其它組件繪製的日曆和任務,基本實現一個完整的線上日程管理功能 先看圖,android和ios上的效果圖如下: 我們可以看到通過deviceone平臺可以實現跨平臺的複雜ui,我們在IDE里可以看到用戶拖拽了很多組件到設計區,通過設置屬性,綁 ...
  • 回到目錄 為何要寫 之所以寫這篇文章,完全是因為學生們在實際開發中遇到的問題,一個對象占用的記憶體空間總不被釋放,導致系統記憶體不斷攀升,其最主要原因是我們對“對象的生與死”不清楚,或者從來沒有認真去考慮過這件事,確實一個對象在被聲音,初始化,使用或者最後被系統回收,整個的過程與我們關係確實不大,我們開 ...
  • 工廠方法模式是對簡單工廠模式的改進,它為每個對象增加了一個工廠類,專門用於生成該對象。 工廠方法實現加減乘除例子如下: 1 操作類 2 為每一個操作類添加一個工廠對象 3 在客戶端使用工廠生產需要使用的對象 運行結果為:3 工廠方法模式把判斷移到了客戶端,並沒有解決判斷實例化哪個對象的問題,但這種模 ...
  • gets()函數存在於#include<stdio.h>或#include<cstdio>頭文件中,而不是#include<string>或#include<cstring>中 C++中,#include<string>和##include<cstring>是兩個不同的頭文件。 你可能弄混的不是兩個 ...
  • * KVO: key(鍵)-value(值)-observer(觀察者) 通過對一個對象、屬性或者變數值的觀察來做出對應的動作 只要key對應的值發生改變 就會告訴觀察者新舊值的變化 通過key來判斷是哪一個KVO 要實現KVO需要的條件: * 1.有觀察者、被觀察的對象 添加觀察者方法: 用誰去調 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發(一):使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說,近來想嘗試開發一款安卓APP,考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP,畢竟是使用Visual Studio開發工具,使用起來也比較的順手,結合微軟官方的教程進行了安卓 ...
  • 前言 QuestPDF 是一個開源 .NET 庫,用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫,它徹底改變了我們生成 PDF 文檔的方 ...
  • 項目地址 項目後端地址: https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址: ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址: http://tree ...
  • 話不多說,直接開乾 一.下載 1.官方鏈接下載: https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe,運行開始下載SQL server; 二. ...
  • 前言 隨著物聯網(IoT)技術的迅猛發展,MQTT(消息隊列遙測傳輸)協議憑藉其輕量級和高效性,已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫,為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog支持多種接收器用於日誌存儲,增強器用於添加屬性,LogContext管理動態屬性,支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項,適用於不同需求。 ...
  • 目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據,爬取信息時需要模擬瀏覽器行為,否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下: 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • 1.前言 什麼是熱更新 游戲或者軟體更新時,無需重新下載客戶端進行安裝,而是在應用程式啟動的情況下,在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR,Xlua,ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles,Addressable, ...
  • 本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺,其實像阿裡雲,騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後,它會送 ...
  • 通過以下方式可以高效,並保證數據同步的可靠性 1.API設計 使用RESTful設計,確保API端點明確,並使用適當的HTTP方法(如POST用於創建,PUT用於更新)。 設計清晰的請求和響應模型,以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證,確保接收到的數據符合預期格 ...