IT生涯將近10年，一直對於軟體架構還是將懂非懂，因為每一個團隊的經歷不一樣，所以達到的高度也不一樣，所以經歷決定一個架構師的水平能力（騰訊的架構也不一定適用中小型，做ERP的不一定適合互聯網），也由於行業的特性，所以架構也隨環境，行業特性，團隊水平性而產生裂變，所以說團隊的技術水平決定架構的層次， ...
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）的升級，在此之前，還有諸如集中式架構、分散式的架構等。這裡借用一副抽象的圖來描述下常見的幾種架構：
微服務架構由多個微小服務構成，每個服務就是一個獨立的可部署單元或組件，它們是分散式的，相互解耦的，通過輕量級遠程通信協議（比如REST）來交互。每個服務可以使用不同的資料庫，而且是語言無關性的。它的特征是彼此獨立、微小、輕量、松耦合，又能方便地組合和重構，個體簡單，但組合起來威力強大。
優點：擴展性好，服務之間耦合性低，服務間相互獨立，容易部署，易於開發，方便測試每一個服務
缺點：容易過度關註服務的大小，可能拆分地很細，導致系統依賴於大量的微服務，而服務之間的相互通信也會變得複雜，系統集成複雜度增加，很難實現原子性操作。
微服務之所以這麼火，另一個原因是因為 Docker與Kubernetes(k8s) 的出現，它讓微服務有一個非常完美的運行環境。Docker 的獨立性和細粒度非常匹配微服務的理念，Docker的優秀性能和豐富的管理工具，讓大家對微服務有了一定的信心，概括來說 Docker 有如下四點適合微服務：
獨立性：一個容器就是一個完整的執行環境，不依賴外部的任何東西。
細粒度：一臺物理機器可以同時運行成百上千個容器，其計算粒度足夠小。
快速創建和銷毀：容器可以在秒級進行創建和銷毀，非常適合服務的快速構建和重組。
搭配Kubernetes(k8s)開源的容器集群管理系統，能夠快速地實現服務的組合和調度，例如雲電腦租用，閑時，就銷毀電腦資源，忙時增加ESC，就是幾分鐘的事情，還可以實現多租戶的使用。
Kubernetes +DOCKER
當然搭配Kubernetes+jenkines持續集成，可以發佈到開發環境，測試環境，生產環境，更是自動化的事情，架構在迭代，做架構其實一直在學習中前進，好的架構和技術要應用於實踐，保持一顆學習的心，才是立根之本。
作者：BON,微信公眾號：ithaidao
