架構是什么？ - wzb153－IT工程師數位筆記本

文章出處

IT生涯將近10年，一直對于軟件架構還是將懂非懂，因為每一個團隊的經歷不一樣，所以達到的高度也不一樣，所以經歷決定一個架構師的水平能力（騰訊的架構也不一定適用中小型，做ERP的不一定適合互聯網），也由于行業的特性，所以架構也隨環境，行業特性，團隊水平性而產生裂變，所以說團隊的技術水平決定架構的層次，再加上架構也是具有一定的發展性（從最初的三層架構，MVC，SAAS，DDD，微服務），所以一直以來，架構在每一個團隊，或者整個軟件行業一直都是霧里看花，也就造成每一個團隊都有自己的一套架構標準。

一,好架構的標準

一個好的架構，必然跟目前的技術推進相關，好的架構必須具備以下的規則：

1，適應于多人開發，保證開發質量的前提下，盡量以效率為主，所以為什么要用ORM，接口規范，公共層，代理層，數據庫設計規范，這些都是為了效率，減少重復代碼工作量，以節省開發時間。

2，良好的可伸縮性，擴展性，所以才有了架構的行業規范。從架構的迭代，大多數人都經歷三層架構，MVC，MVP（WEB FROM ），SAAS，DDD，微服務，組件，插件化，架構，這些的技術單一或者混合在使用，這些都是為了伸縮以及可擴展性，并且由于一般大型的開發，人員很多，所以把每一個大型的系統拆分成子系統，有利于松藕及管理，所以一個大型的系統拆分子系統又有很有必要，像淘寶，分支付系統，商品系統，搜索系統，存儲系統等。

3，為了應付大并發，海量數據，不同的小組工作成員分工，那么就大量的中間件運用而生,而分布式的中間件大量產生，緩存（Cache），消息隊列（MQ），任務調度（JOB），搜索引擎，存儲引擎，數據庫讀寫分離，數據挖掘引擎，大量應用而生，所以導致很多人認為架構不與這些沾上邊，就是以為那就不是好的架構，因為這些的應用場景比較缺，所以也是考驗一個開發的技術水平，沒有平臺給你做實踐，天天談技術純粹扯蛋，只要真的踩坑，才是出真理。

4，不同的行業背景，架構也不一樣，舉個例子：

ERP類行業標準：金碟的K/3系統，之前每一個庫留幾十個字段，那是因為客戶端以及服務端到實施他沒有云化，所以預留字段很有必要，所以大型應用組件及插件，客戶在實施的時候，需要什么，按需調用，為了靈活性及通用性。

互聯網類的標準：從最初的三層架構，到SAAS（SOA，軟件即服務），DDD（領域驅動），微服務，每一個技術的發展，其實是跟整個互聯網的背景有關，為什么會有微服務，其實是跟技術環境有關系，由于互聯網代表新興的技術推進，面臨各種技術的混合使用，云平臺的誕生，所以才會有微服務的存在，微服務最大的優點就是為了跨平臺以及跨語言，其缺點也很明顯，可能導致重復的工作。

那么，歸納起來，衡量一個架構的好壞，可以從以下5個方面去考慮大并發，海量數據，擴展性，獨立性，業務延伸五個方面去達到考慮一個架構的規范及嚴謹性。

按照以上的五個標準，那么我根據自己的水平以及層次，建立一套好的框架標準，肯定是要考慮結合實踐場景，那么客戶必須滿足三個端，網站（PC與移動），APP，物聯網硬件，而服務端必須滿足獨立性，擴展性，大并發及海量數據，如電商為例：

1,服務端，可劃分為載體，構件層，組件層，（載體是指，WEB項目，WEBAPI，SOCKET服務中心管理，任務調度管理中心，構件層很重要的一個功能就是將系統資源與應用構件隔離，這是保證構件可重用甚至"即插即用"的基礎，與中間件的意圖同樣是一致的，簡潔理解為，構件可以加載到任務載體，載體可以隨便選擇構件，通過IOC就可以實現他的功能引用，組件就是元件）即插即用，用到這載體，構件化，組件化，實現擴展性，獨立性，業務延伸的一個標準。

而把運營支持組件，嵌入到組件里面去，可以實現支撐大并發，海量數據，有利于系統的統一性，而運營組件最大目的就是支撐大并發以及海量數據，例如：緩存減少IO讀寫，消息隊列把同步變成異步，多表聯合查詢用搜索引擎替換，NOSQL，HADOOP替換了數據庫運算……

而這樣就有了一個好的架構，那么說一說規范以及技術在架構的應用以及規范，架構的目的是在于規范，而規范遵守三個標準：約定、規則、共識。

一，組件的標準定義，擁有數據實體層Model，服務層Services，數據層DAL.

約定標準以下：

1.1，MODEL層的規則就是可以建立數據表之間的一對多，或者一對一，超過之外的視圖模型統一放到構件層的DTO（WEB API），或者載體（WEB項目）的MODEL管理，以便減少維護成本。

1.2，Services盡量以接口暴露出來，加上IOC可以注入到任何的載體容器里面去。如JAVA的SPRING框架，NET的WEBAPI，MVC框架。

1.3,services層調用DAL盡量引用單例模式，這樣在讀寫分離起到作用。

1.4，ORM的標準，支持不同的數據庫類型，例如：MYSQL，NOSQL，MSSQL，ORACLE，框架選型，根椐不同的開發語言，做不同的選型，最重要的一點，支持讀寫分離。

1.5在services層添加一個IOC的接口配置文件，這樣把IOC配置在WEB項目，或者WEBAPI這樣的載體上面上。

二構件的標準定義：

2.1 獨立的路由URL，Controller，DTO，所有的數據來源都是組件。為什么會需要構件？在軟件交互的時候，很多時間我們面臨三個問題：

1：由UI，客戶端，第三方接口與目前的系統模型沒法對應，需要過濾及組裝。

2：需要對內外統一通過URL路徑及通訊協議。

3：跨平臺，降低程序的復用性，一個暴露的接口，每個子系統都可以引用。

運營組件的標準：

1，分布式CACHE，作二級緩存使用，減少IO讀寫，以應用大并發，以內存讀寫速度換IO讀寫速度。

2，消息隊列，在對一個同步的機制化解成異步處理，主要目的是減少請求響應時間和解耦。

3，任務調度，以任務方式，實現任務的調度，這個有利于資源的分配，例如：閑時做數據清洗（ELT），數據庫備份，消息推送等。

4，搜索引擎中間件，替換數據庫的實時查詢，例如：多表關聯查詢，視圖查詢，一般可以采用搜索引擎機制進行查詢。

5，數據挖掘引擎，可以搭配HADOOP，SPARK進行實時運算，并把實時結果返回。

運營組件的標準：

一，分布式CACHE作二級緩存使用，減少IO讀寫，以應用大并發，以內存讀寫速度換IO讀寫速度。

優點：簡單有效，減少對 DB 的查詢
缺點：增加邏輯判斷，不適合存儲大對象。

二，消息隊列在對一個同步的機制化解成異步處理，主要目的是減少請求響應時間和解耦，以便提高吞吐量。

優點：異步、解耦，提高吞吐量
缺點：消息消費延遲等問題

三，任務調度以任務方式，實現任務的調度，這個有利于資源的分配，例如：閑時做數據清洗（ELT），數據庫備份，消息推送等。

優點：利用閑時提高資源的使用量，
缺點：帶來開發成本以及維護成本

四，搜索引擎中間件替換數據庫的實時查詢，例如：多表關聯查詢，視圖查詢，一般可以采用搜索引擎機制進行查詢。

優點：利用索引可以替換多表聯合查詢，視圖查詢，減少數據庫查詢帶來的不便性
缺點：要做到實時數據有點困難

五，數據挖掘引擎可以搭配HADOOP，SPARK進行實時運算，并把實時結果返回。

優點：可以代換傳統數據庫的實時運算，并根據算法達到最優
缺點：需要數據清洗，不同的算法來做不同維度的模型，技術含量高。

六、數據分庫

先垂直后水平的原則，根據業務的進行解藕，一般按業務的來劃分，因為前面搭配了搜索引擎，以及HADOOP來替換數據庫的實時運算，一般沒大問題，所以前提盡量先拆庫，再拆表。

數據庫標準：

前期盡量按業務或者子系統分庫，另外數據庫的設計標準，盡量減少字段以及字段存儲，達到以空間換時間的效果，即存儲量越小，查詢越快。

談完以上，就可以開始著手搭一個架構出來，再根據業務場景去進行編碼去，規范再定義好數據庫規范，代碼審核規范，即可以完成一個軟件架構了。

當然，實時這些，只能是從軟件架構的實現，現實還要進行

1. 數據庫服務集群（一寫多臺讀）

2. 文件服務集群。

3. 緩存服務集群

4. 應用服務集群

5. 負載均衡調度器集群

6. 靜態內容服務集群

7. CDN服務器集群

優點：去單點，高可用

缺點：數據有狀態問題、數據一致性問題，資源成本、人力維護成本都上去了。

這樣一個大型的網站架構就完成了但這也面臨一個很現實的問題，一個網站的流量并發有高有低，包括發布，在一百臺機器發布程序以10臺發布完成不一樣，還有多個子系統，發布簡直就是浪費人力成本，而 DT/分布式時代的到來，大流量和大數據的場景的出現，包括Docker ，Kubernetes技術的產生，一度催生了微服務架構。

微服務架構

微服務架構（microservices architecture）一度成為熱點，微服務并不是憑空出現，有人說，它是面向服務架構（SOA）的升級，在此之前，還有諸如集中式架構、分布式的架構等。這里借用一副抽象的圖來描述下常見的幾種架構：