導讀ID:TOP100case
導語：軟件架構是軟件的生命，活力和骨架，它隨着時間而成長和演化，不變的軟件架構是一具僵屍而已。《設計之美》提到，無情的重構，架構就會產生。而這種架構成長的動力在哪里？其動力就在於業務的增長，一切不為業務服務的架構演化都是耍流氓！
本文將從作者多年的實踐經驗出發，解讀什么是架構和業務，微服務架構，以及架構演化如何促進業務增長，文章還闡述了架構師這一角色如何處理復雜問題。
（全文共3518字 預計閱讀時長：4分鍾）
什么是架構和業務
大師Grady Booch將軟件架構解釋為架構是一種設計，但並非所有設計都是架構。架構代表着發展一個系統的重要決定，而這種重要性是通過引入變化的成本來衡量的。
有一本書叫做《恰如其分的軟件架構》Just Enough Software Architecture（A Risk-Driven Approach），里面有一種觀點，就是對於特定的一個系統，需要做多少相應的架構設計工作呢？如果設計工作容易開展，風險小，也許不需要太多架構投入；如果設計工作風險大，牽一發而動全身，那么就需要加大架構的規划。
引入變化成本將成為架構決策的重要因素，這與我的想法不謀而合，其實架構的演化是與業務息息相關的。所謂業務，從經濟學來說，就是利潤＝收入－成本，那么架構在演化的時候必須尊重這個基本法則。架構的核心目標是支持業務，增加收入，降低成本，減少費用。
如果你也想在IT行業拿高薪，可以參加我們的訓練營課程，選擇最適合自己的課程學習，技術大牛親授，7個月后，進入名企拿高薪。我們的課程內容有：Java工程化、高性能及分布式、高性能、深入淺出。高架構。性能調優、Spring，MyBatis，Netty源碼分析和大數據等多個知識點。如果你想拿高薪的，想學習的，想就業前景好的，想跟別人競爭能取得優勢的，想進阿里面試但擔心面試不過的，你都可以來，群號為：71859422
注：加群要求
1、具有1-5工作經驗的，面對目前流行的技術不知從何下手，需要突破技術瓶頸的可以加。
2、在公司待久了，過得很安逸，但跳槽時面試碰壁。需要在短時間內進修、跳槽拿高薪的可以加。
3、如果沒有工作經驗，但基礎非常扎實，對java工作機制，常用設計思想，常用java開發框架掌握熟練的，可以加。
4、覺得自己很牛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、具有1-5工作經驗的，面對目前流行的技術不知從何下手，需要突破技術瓶頸的可以加。
2、在公司待久了，過得很安逸，但跳槽時面試碰壁。需要在短時間內進修、跳槽拿高薪的可以加。
3、如果沒有工作經驗，但基礎非常扎實，對java工作機制，常用設計思想，常用java開發框架掌握熟練的，可以加。
4、覺得自己很牛B，一般需求都能搞定。但是所學的知識點沒有系統化，很難在技術領域繼續突破的可以加。
5.阿里Java高級大牛直播講解知識點，分享知識，多年工作經驗的梳理和總結，帶着大家全面、科學地建立自己的技術體系和技術認知！
6.小號或者小白之類加群一律不給過，謝謝。
目標已經有了，下面就看行動了！記住：學習永遠是自己的事情，你不學時間也不會多，你學了有時候卻能夠使用自己學到的知識換得更多自由自在的美好時光！時間是生命的基本組成部分，也是萬物存在的根本尺度，我們的時間在那里我們的生活就在那里！我們價值也將在那里提升或消弭！Java程序員，加油吧