架構是什麼？

    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讀寫速度。

1. 優勢：簡單有效，減小對 DB 的查詢

2.  

   缺點：增長邏輯判斷，不適合存儲大對象。

 

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

1. 優勢：異步、解耦，提升吞吐量

2. 缺點：消息消費延遲等問題

 

 

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

1. 優勢：利用閒時提升資源的使用量，

2. 缺點：帶來開發成本以及維護成本

 

 

四，搜索引擎中間件替換數據庫的實時查詢，例如：多表關聯查詢，視圖查詢，通常能夠採用搜索引擎機制進行查詢。

1. 優勢：利用索引能夠替換多表聯合查詢，視圖查詢，減小數據庫查詢帶來的不便性

2. 缺點：要作到實時數據有點困難

 

 

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

• 優勢：能夠代換傳統數據庫的實時運算，並根據算法達到最優

• 缺點：須要數據清洗，不一樣的算法來作不一樣維度的模型，技術含量高。

 

6、數據分庫

 

先垂直後水平的原則，根據業務的進行解藕，通常按業務的來劃分，由於前面搭配了搜索引擎，以及HADOOP來替換數據庫的實時運算，通常沒大問題，因此前提儘可能先拆庫，再拆表。

 

數據庫標準：

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

 

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

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

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

2.    文件服務集羣。

3.    緩存服務集羣

4.    應用服務集羣

5.    負載均衡調度器集羣

6.    靜態內容服務集羣

7.    CDN服務器集羣

優勢：去單點，高可用

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

 

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

 

微服務架構

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

微服務架構由多個微小服務構成，每一個服務就是一個獨立的可部署單元或組件，它們是分佈式的，相互解耦的，經過輕量級遠程通訊協議（好比REST）來交互。每一個服務可使用不一樣的數據庫，並且是語言無關性的。它的特徵是彼此獨立、微小、輕量、鬆耦合，又能方便地組合和重構，個體簡單，但組合起來威力強大。

 

優勢：擴展性好，服務之間耦合性低，服務間相互獨立，容易部署，易於開發，方便測試每個服務

缺點：容易過分關注服務的大小，可能拆分地很細，致使系統依賴於大量的微服務，而服務之間的相互通訊也會變得複雜，系統集成複雜度增長，很難實現原子性操做。

微服務之因此這麼火，另外一個緣由是由於 Docker與Kubernetes(k8s) 的出現，它讓微服務有一個很是完美的運行環境。Docker 的獨立性和細粒度很是匹配微服務的理念，Docker的優秀性能和豐富的管理工具，讓你們對微服務有了必定的信心，歸納來講 Docker 有以下四點適合微服務：

 

獨立性：一個容器就是一個完整的執行環境，不依賴外部的任何東西。

細粒度：一臺物理機器能夠同時運行成百上千個容器，其計算粒度足夠小。

快速建立和銷燬：容器能夠在秒級進行建立和銷燬，很是適合服務的快速構建和重組。

搭配Kubernetes(k8s)開源的容器集羣管理系統，可以快速地實現服務的組合和調度，例如雲計算機租用，閒時，就銷燬計算機資源，忙時增長ESC，就是幾分鐘的事情，還能夠實現多租戶的使用。

 

 

Kubernetes  +DOCKER

 

固然搭配Kubernetes+jenkines持續集成，能夠發佈到開發環境，測試環境，生產環境，更是自動化的事情，架構在迭代，作架構其實一直在學習中前進，好的架構和技術要應用於實踐，保持一顆學習的心，纔是立根之本。

 

 

 

 

做者：BON,微信公衆號：ithaidao