1.最近本人整理了一下，公司所用的架構，以及看了一些大公司使用的架構體系，思考了很多，其中最讓我感興趣的是企業級架構發展在哪裡，以及未來的方向？這個問題可能要用很長的時間讓我去揣摩一下。我先介紹一下現在企業級應用架構的解析。 一.原始版。
特點：單節點，幾乎無容災，負載能力低，維護簡單。 個人分析：這個是我們剛開始學習所用的架構。 二.動靜分離版。
特點：Nginx通路靜态資源，Nginx負載均衡，應用分離，依賴架構，安全性低，Session 持久化問題（容易出現會話粘連，隻有用cookie 進行session 的存儲，容易被人修改有點坑爹）。 個人分析：減少了伺服器和使用者之間互動的流量，這個版本一般都用了一些spring，mybatis等第三方架構。
三.緩存版
特點：大量使用緩存，Nginx接收Https，Session 持久化，一緻性問題，緩存失效問題。 個人分析：緩存存儲usersession 中。資料庫和緩存沒有資料一緻性同步資料的功能，資料庫有可能有峰值通路可能導緻資料庫崩潰。
四,分布式服務版
特點：小型機虛拟化，請求處理與業務拆分，應用服務化，同步異步拆分，資料庫讀寫分離，運維難度大大增加。 個人分析：dubbo 可以服務路由，負載均衡，調用統計，将應用 部署小型機虛拟服務中。消息中間件RabbitMQ可以背景服務可以均勻的消費這些消息,排程中間件SchedulerX(阿裡巴巴)。資料庫的讀寫分離。 五.彈性計算版
特點：容器級虛拟化，應用資源動态配置設定，離線資料采集分析系統，資料庫讀寫分離，硬體成本下降，異地容災。 doker 容器級的虛拟化，可以使伺服器的資源實時配置設定。 個人分析：doker 确實是實作彈性計算的有簡便的方式，它能夠很快的複制節點，比如說a 機房出現問題了，他能夠快速的在b機房部署服務應用，這邊還是用了hadoop 的日志收集系統。這裡的資料庫不在和應用直連，而是采用了資料庫的中間件例如：淘寶的（tddl）,有中間件路由表，資料庫的操作與開發人員隔離，也可以讓hadoop 計算寫入資料庫。
架構的基本原則： 1.CAP原則：（一緻性，高可用，分區容錯性） 2.複雜的事情簡單化。
架構的目的： 1.高速緩存 2.并行計算 3.負載均衡 4.資料備份（主從的備份，線上庫離線庫的備份） 5.異地容災（部署到多個機房） 6.業務分離
總結：其實在做架構的時候不是每個架構都要朝着最新最前沿的技術走，我覺得應該找尋一個最适合團隊内部的開發的架構，在日常的開發中，由于開發人員技術儲備，還有項目的需求等問題，我們應該根據整體的情況來進行架構，而不是盲目的跟風。現在我們公司的開發架構屬于分布式服務簡單版，而我現在也在學習彈性版所需的技術，有興趣的小夥伴們希望在我的部落格中留言，多多指教。