架構師須知道的架構發展過程及趨勢

導讀ID:TOP100case

導語：軟件架構是軟件的生命，活力和骨架，它隨着時間而成長和演化，不變的軟件架構是一具殭屍而已。《設計之美》提到，無情的重構，架構就會產生。而這種架構成長的動力在哪裏？其動力就在於業務的增加，一切不爲業務服務的架構演化都是耍流氓！

本文將從做者多年的實踐經驗出發，解讀什麼是架構和業務，微服務架構，以及架構演化如何促進業務增加，文章還闡述了架構師這一角色如何處理複雜問題。

（全文共3518字 預計閱讀時長：4分鐘）

什麼是架構和業務

大師Grady Booch將軟件架構解釋爲架構是一種設計，但並不是全部設計都是架構。架構表明着發展一個系統的重要決定，而這種重要性是經過引入變化的成原本衡量的。

有一本書叫作《恰如其分的軟件架構》Just Enough Software Architecture（A Risk-Driven Approach），裏面有一種觀點，就是對於特定的一個系統，須要作多少相應的架構設計工做呢？若是設計工做容易開展，風險小，也許不須要太多架構投入；若是設計工做風險大，牽一髮而動全身，那麼就須要加大架構的規劃。

引入變化成本將成爲架構決策的重要因素，這與個人想法不謀而合，其實架構的演化是與業務息息相關的。所謂業務，從經濟學來講，就是利潤＝收入－成本，那麼架構在演化的時候必須尊重這個基本法則。架構的核心目標是支持業務，增長收入，下降成本，減小費用。

若是你也想在IT行業拿高薪，能夠參加咱們的訓練營課程，選擇最適合本身的課程學習，技術大牛親授，7個月後，進入名企拿高薪。咱們的課程內容有：Java工程化、高性能及分佈式、高性能、深刻淺出。高架構。性能調優、Spring，MyBatis，Netty源碼分析和大數據等多個知識點。若是你想拿高薪的，想學習的，想就業前景好的，想跟別人競爭能取得優點的，想進阿里面試但擔憂面試不過的，你均可以來，羣號爲：71859422

注：加羣要求

一、具備1-5工做經驗的，面對目前流行的技術不知從何下手，須要突破技術瓶頸的能夠加。

二、在公司待久了，過得很安逸，但跳槽時面試碰壁。須要在短期內進修、跳槽拿高薪的能夠加。

三、若是沒有工做經驗，但基礎很是紮實，對java工做機制，經常使用設計思想，經常使用java開發框架掌握熟練的，能夠加。

四、以爲本身很牛B，通常需求都能搞定。可是所學的知識點沒有系統化，很難在技術領域繼續突破的能夠加。

5.阿里Java高級大牛直播講解知識點，分享知識，多年工做經驗的梳理和總結，帶着你們全面、科學地創建本身的技術體系和技術認知！

6.小號或者小白之類加羣一概不給過，謝謝。

目標已經有了，下面就看行動了！記住：學習永遠是本身的事情，你不學時間也不會多，你學了有時候卻可以使用本身學到的知識換得更多自由自在的美好時光！時間是生命的基本組成部分，也是萬物存在的根本尺度，咱們的時間在那裏咱們的生活就在那裏！咱們價值也將在那裏提高或消弭！Java程序員，加油吧

什麼是架構和業務

互聯網軟件的架構大部分都是從三層結構開始的:前端、業務邏輯層、數據庫。這多是大部門業務在初創階段須要的，爲啥這種結構？這是一種解耦，將變化快、中、慢三個層次的模塊分爲三個部分。前端變化最快，獨立起來，中間業務邏輯變化次之，數據層相對穩定。

這樣不一樣速度的變化，能夠在本身的賽道上按本身的節奏走。另一個重要緣由是Conway法則，軟件的架構老是和組織結構有關，工程師很容易分紅前端工程師，服務端工程師和數據庫DBA。

軟件架構的演化

那麼三層結構是否就無敵了麼？在實踐工程中，三層結構也很多煩惱，例如一般一個需求會涉及到幾個層次的修改，而這種修改須要分散在不一樣的工程角色中，那麼協調的成本很高，排期的過程也要服從木桶原理，最慢的工序將決定最後的發佈時間。各個層次的耦合愈來愈多，愈來愈繁雜。

舉個例子，邏輯層爲了加快訪問速度，會引入Cache層，這樣數據就可能分佈在Cache裏，或者數據庫層。另外，業務層的數據來源可能不所有來源於數據庫，不少來源於離線的數據處理腳本，這些數據一般會存放在NoSQL中，例如Redis，HBase等。再進一步發展就是，各個業務使用NoSQL的模式也不同，有的業務數據量巨大，訪問延遲很慢，有的只是配置文件，須要實時更新。隨着業務發展，業務層開始使用其餘第三方的服務，經過服務接口獲取數據。最後，這就慢慢造成了一個網狀的服務依賴和數據依賴。

慢慢的，簡單的三層結構漸漸墮落成無序的網狀結構了。對於網狀結構的初期，線上特別容易出問題，容易形成雪崩效應，一個模塊的變化容易改變整個系統的服務能力（若是你的架構沒有出現過這個問題，也許說明你的業務發展的不夠快，不夠複雜）。在流量增加迅猛的時候，你們會被迫忙於解決線上問題，架構師也開始謀劃架構的長期演化。

不少同窗會說，爲啥不早早就把架構規劃好呢？可以早早把架構規劃化，無憂無慮的開發公司估計都破產了，舉例來講，有些電商公司在發展初期，對因而作平臺仍是作服務經常是爭論不休的，這樣適合的架構也不容易落地的。京東從ASP.NET轉向Java，從面向技術的架構轉型爲面向業務的架構，都是適合業務自發展的需求，從技術角度來看並不是是最理想的解決方案。

人們對於過多的層次理解老是有限，通常人對於超過3層的結構，基本就糊里糊塗了，好比說OSI定義了7層結構，可是最流行的確實是TCP/IP的4層結構；J2EE定義的層次複雜性嚇的不少創業人，敬而遠之，這就是一些輕量級的Spring等框架大行其道；MFC類的繼承關係超過3層，開發者基本上就找不到北了，目前還有不少討論。所以，對於架構的設計，應該服從簡單的原則。

解耦是架構演化的核心問題

按照業務進行系統切分是必須通過的一個過程，分而治之，獨立自由發展，這也是業務快速發展初期的必由之路。解耦一般是很痛苦的一個過程。

解耦有不少方式，一般採用如下的一些技術：

• 最一般的是引入隊列，經過生產者和消費者模式，減小兩個模塊的耦合度。

• 經過反轉註入IOC，經過配置定義不一樣的實現。

• 採用事件驅動的設計模式，包括觀察者模式，消息鏈模式等。

解耦以後，整個系統會清爽不少，代碼結構會變得很清楚，處女座的同窗能夠開心一陣子了。解耦能夠幫助處理部分的性能問題，特別是異步化的調用。可是，解耦並無解決各個模塊的擴容問題。解耦只是之前纏在一塊兒的問題，解開在不一樣的獨立服務和服務之間的鏈接中。例如，在經過Kafka隊列解耦過程當中，隊列堆積是常常碰到的問題，如何從監控，控流，容錯等方面，改進碰到的問題就是解耦後面首要解決的問題。

在擴容的過程當中，會碰到不少瓶頸，這些瓶頸每每是一個接一個的出來，就像打地鼠同樣，打死一個，出來一個，打死兩個，出來一對。固然，前提是業務的高速發展。

處理架構的瓶頸

如何處理擴容問題，核心是找到系統的瓶頸，常見的瓶頸包括下面的狀況：

●5.1 數據寫瓶頸

• 內存先作聚合，到必定量後統一寫入數據；

• 採用NoSQL技術；

• 水平分庫和垂直分庫。

●5.2計算瓶頸

計算瓶頸常常出如今複雜數學模型的計算，隨着Features的增多，計算時間變長。計算瓶頸一般須要自定義解決方案，例如內存換時間，分佈式計算，分級服務。

例如在搜索引擎中，對於商業性潛力大的查詢，能夠花費更多的計算。對於長尾詞，能夠減小計算的層次，以達到節省計算的成本。

●5.3存儲瓶頸

存儲成本幾乎是每個爆發性增加業務都要碰到了，存儲包括日誌，圖片和數據等。存儲一般分佈在內存，緩存，SSD，磁盤等地方。內存不夠用是常見的最大問題，內存一般都被數據塞滿了，分佈式NoSQL一般是實用的解決方案，若是數據仍是大，那麼可能須要作索引，可使用Elastics Search，Lucence等。

現代軟件的架構SOA

談到架構，咱們都會提到SOA，這是一個老話題，到底什麼是面向服務的架構？SOA是經過分佈式的服務模塊來構建軟件系統，服務之間經過接口契約聯繫起來，而避免了不一樣模塊之間採用不一樣的方式交換數據，例如文件交換，內存共享，數據庫直連等方式。這種方式改善了封裝，複用和解耦等方面，適用於複雜的大規模系統。

SOA的第一批實現基本都是企業級別的，例如Java 的ESB(企業服務總線），實現過於笨重，部署過於複雜。與此同時，各個互聯網企業也基於SOA進行大量開發工做，也積累了不少SOA，特別是分佈式的經驗。

爲了加快SOA的開發節奏，充分利用雲部署的架構進行水平擴展，一種輕量級的SOA方法正在慢慢的流行起來,這就是微服務。

微服務化的趨勢

微服務是組織和利用分佈式能力的一種模式，微服務提供一個高性能的服務接口，是進程之上的一種模式。提供獨立的業務能力,特別強調的是，獨立的業務能力；微服務是用一組服務來構建應用，服務獨立部署在不一樣進程中，不一樣服務經過輕量級的交互來通訊，例如RPC，HTTP，服務可獨立擴展和伸縮，每一個服務定義了明確的邊界，獨立團隊來維護。

微服務特徵包括如下8個方面：

• 組件化；

• 業務組織團隊；

• 服務就是產品；

• 去中心化；

• 基礎設施自動化；

• 容錯設計；

• 計劃設計；

• 服務質量保證。

架構的角色篇

雖然對於軟件架構的技術有不少研究、發展、創新，但對於架構師這個角色卻缺乏經驗，例如對於公司是否須要專職架構師有多種不一樣意見。不少公司的架構師其實是開發經理或者研發總監擔當，由於架構師直接帶領團隊，所以架構演化執行的效率高。

可是也有不少公司（例如微軟）的架構師是一個IC角色，換句話說他們須要靠本身的影響力推進架構演化和升級，而開發經理更加直接面對業務需求，這個時候短時間業務開發和架構長期演化須要在不一樣的角色中達到平衡。

這種不一樣實踐的核心問題是「對定一個系統，須要多少專門的架構設計工做？」一個關鍵問題是，若是一個項目沒有太多的設計風險，說明架構在一個好的狀態，不須要太多的架構工做；若是一個系統的設計風險很大，每個業務實現都須要過多的考慮設計風險，那麼說明這個項目的架構須要大力投入了。這就是風險驅動的架構設計。

架構師如何處理複雜問題

架構師在面對複雜問題時，像不少人同樣，首先收集足夠多的數據，將問題描述清楚，抽象來講，架構師處理複雜問題的三種基本方法：分解（分而治之）、抽象（大象無形）、知識庫（見多識廣）。

• 分解一般是按照必定的角度對系統進行拆分，角度一般是按照業務、功能和團隊等方式來作。舉例來講，若是是國內和國外的合做項目，儘可能會選擇沒有減小依賴的方式來拆分和項目管理。分解以後的聯繫一般使用簡單、可靠的接口來定義，包括SLA等。

• 抽象是屏蔽了細節的一種方式，就像大象無形，不少人真正把架構問題想透之後，抽象到最簡單和基本的問題，就容易推進架構的演化。舉一個例子，飛機是很是複雜的，可是若是將飛機制造抽象成物理部件系統、空調系統、機電系統、光電系統，等等，那麼理解起來的難度就會下降不少。

• 利用知識庫也是架構師重要的技能，利用互聯網快速找到相關的信息，多學習學習別人走過的路，踩過的坑。早年的軟件工程所強調的領域工程，也是但願經過工程化的方式，把已經有的行業知識積累起來，爲他人所用。

若是你也想在IT行業拿高薪，能夠參加咱們的訓練營課程，選擇最適合本身的課程學習，技術大牛親授，7個月後，進入名企拿高薪。咱們的課程內容有：Java工程化、高性能及分佈式、高性能、深刻淺出。高架構。性能調優、Spring，MyBatis，Netty源碼分析和大數據等多個知識點。若是你想拿高薪的，想學習的，想就業前景好的，想跟別人競爭能取得優點的，想進阿里面試但擔憂面試不過的，你均可以來，羣號爲：71859422

注：加羣要求

一、具備1-5工做經驗的，面對目前流行的技術不知從何下手，須要突破技術瓶頸的能夠加。

二、在公司待久了，過得很安逸，但跳槽時面試碰壁。須要在短期內進修、跳槽拿高薪的能夠加。

三、若是沒有工做經驗，但基礎很是紮實，對java工做機制，經常使用設計思想，經常使用java開發框架掌握熟練的，能夠加。

四、以爲本身很牛B，通常需求都能搞定。可是所學的知識點沒有系統化，很難在技術領域繼續突破的能夠加。

5.阿里Java高級大牛直播講解知識點，分享知識，多年工做經驗的梳理和總結，帶着你們全面、科學地創建本身的技術體系和技術認知！

6.小號或者小白之類加羣一概不給過，謝謝。

目標已經有了，下面就看行動了！記住：學習永遠是本身的事情，你不學時間也不會多，你學了有時候卻可以使用本身學到的知識換得更多自由自在的美好時光！時間是生命的基本組成部分，也是萬物存在的根本尺度，咱們的時間在那裏咱們的生活就在那裏！咱們價值也將在那裏提高或消弭！Java程序員，加油吧