多年來對架構的認知

前言

      10多年工做經驗，目前由於大專學歷，半年找不到工做，纔有空總結一下。

在脈脈等平臺看到了不少文章，不少沒用的，不提了。也有一些文章，只是看中某些具體的框架，好像會了及厲害了，我我的的理解 概念和經驗很重要，那些東西只是選型。

      Java這行，出新東西的速度很快，但最終服務於業務，這沒錯，但這只是半句，還有半句是，要根據生產環境進行不斷的調整。

其實，你的架構圖在白板上畫出來，反覆的去揣摩各個點，不斷的細化，解決了一個一個瓶頸以後，會發現這纔是真正的經驗，我的見解。

1、垂直框架

     這是最基本的形式了，典型的表明是SSH、SSM，基本的MVC結構，以JSP爲頁面的多一些，struts或者springMVC來接收請求，業務層service用spring處理已是基本作法，spring從1.0開始，最核心的就是容器和Bean，省了不少事情。以後Dao，用hibernate或者mybaties比較多。

     至於中間是否還用了其餘東西，看具體環境和需求了，好比緩存、消息等等。

     特色：

1. 搭建簡單，主要的是4部分，頁面，通常jsp和html，vue之類也能夠作怎麼佈局了；web層，經常使用不少，springboot、springMVC等，特殊一點的是wicket相似於swing寫法的wicket，但安全性很高，固然還有基於servlet的非開源，3.0之後，web.xml不用寫了，說實話，有web.xml挺方便的。
2. 對分佈式session的支持

        之因此考慮這點，是基於負載，有些網站是採用這種框架，外包的多一些，不支持分佈式session，會在訪問比較大的時候作負載麻煩，nginx通常策略是ip輪詢和iphash。通常方式有兩個：

       1）基於shiro，經過在緩存中保存session，能夠實現session共享，wicket不行，至少7.0版本還不行，得到session的模式不一樣，真弄出來恐怕會比較麻煩。

       2）基於tomcat設置，tomcat好像是6.0開始支持的，經過一些設置，實現內存中一些東西在多個tomcat間複製，但springboot已經不須要依賴單獨安裝的tomcat了

       我的觀點：shiro主要功能是管理權限，但能解決分佈式session問題，即便用shiro，我的仍是更傾向於使用單獨安裝的tomcat，tomcat支持不少，不少東西集中在代碼裏去處理，當發生區別的時候，代碼多套，不如多個tomcat不一樣設置。

2、分佈式框架（這裏不包含微服務）

     分佈式，我不看各類小編寫的概念，根據工做中實際的體會，大致意思是，職能分散。具體狀況中，更多的是按照業務操做劃分的，一個操做是一個接口，同類的操做放在一個服務裏面。固然，也有拆得細的，有點相似於微服務了。舉個例子，好比下訂單：請求進了controller之後，只有一個參數整理邏輯，而後調用訂單服務的下訂單接口，也許下訂單接口中會判斷是不是會員，調用會員服務去新建用戶。

     好處：

      1）分佈式服務剛開始更多的是職能分開，不一樣的職能使用次數是不同的，負載權重在這方面能夠更加靈活。

      2）增長一個職能，可能只須要修改某個服務，不須要所有從新部署了。

      3）職能服務分開，從產品到研發的分工也能夠更細，有的產品和研發只負責零售、有的只負責訂單，固然有的公司作不到。

     特色：

      1）  服務間多采用http，webservice，固然，也用過hession和thirft。

      2）大部分服務間走內網，有一部分須要暴露供外網調用。

3、微服務框架

     微服務，在必定程度上能夠說是分佈式服務的再細分，但也不是絕對的，微服務拆分的服務功能相對單1、獨立，具備獨立的緩存和DB資源，單1、獨立的功能決定了這個服務不止能夠給一個平臺提供服務，相似於支付。舉個例子：

好比快遞，快遞須要與第三方對接，原來的方式：放在訂單服務一塊兒，發完快遞，單號保存在訂單上，若是第一次快遞失敗，從新發，須要把新快遞單號更新到訂單上。微服務方式：快遞做爲單一服務，有獨立的DB和緩存，對外提供下快遞單、查詢的接口，最終業務流程可能不變，基於業務流程也沒發現好處。能夠對比一下哪裏不同了：

1. 快遞是可查的了，不論發多少次，有記錄了
2. 若是合做方變動，不須要動訂單服務，訂單服務的重要性都知道的。
3. 快遞能夠給訂單服務提供下單，那其餘系統是否能夠呢？只要注意了冪等原則，有什麼不能夠。

    微服務如今用rpc形式去作的比較多，hession、dubbo只支持Java，thrift能夠跨語言，serviceMesh我還沒用過，不太清楚。另外關於springcloud系列，feign的調用方式挺好的，我只是對於裏面的一些變革有本身想法，關於減小配置文件，利用註解在代碼裏寫，對於開發來說有些東西方便了，寫法上隨便一些了。但真的方便了嗎？好像是spring3.0之後支持的packageScan，那配置文件中寫的bean，都會是一些比較特殊的，在代碼和配置文件中哪一個好找？雖然還支持寫在配置文件中，但好多文章宣傳這麼寫，也並無舉例說明好處，在我看來像是跟風，怎麼用仍是看實際狀況。

4、聊聊架構

     在個人概念中，架構和框架不是同一個概念，能搭框架跟架構徹底不是一碼事。

     我考慮架構，會包含如下這些，順序不是絕對的，沒有備稿，只是隨手寫的隨筆，可能會寫少了。

　　從請求的方向：

     1.  頁面資源，網站、移動站、crm、app等，

　　放在CDN的：

         1）靜態資源，圖片、css、js

         2）動態加載的頁面，指的頁面上有一部份內容是利用相似jquery的documentReady的事件去加載的，這樣的頁面，除了CDN回源的時候服務器會有流量，其餘時候，只會訪問接口。

          先後端分離的基於nodejs的響應式前端了解不太多，沒處理過。

     2.分流

依賴的中間件是nginx、haproxy之類，通常是ip輪詢或者iphash策略，通常狀況下，沒有分佈式session問題，就能夠用ip輪詢了。作足球票搶票的時候，由於老框架用的wicket，因此用的iphash，4臺服務器橫向擴展，只有第一臺壓力是最大的，這個問題還不是臨時能解決的。先後端分離之後，session的key記在前端了，這個問題也就解決了。

頁面與服務間，http請求的分發可使用nginx之類，有條件的再上lvs，設置dns服務商那裏作ip輪詢。如今微服務主要是rpc形式，rpc目前都有基於zookeeper的方案，但zookeeper是編程式的註冊和卸載node，這點確實從15年之前就不喜歡。雖然是rpc，但都是tcp請求，之前就弄過haproxy+thrif的結構，如今nginx也支持tcp了。

    3.跨語言

     展現端也許是頁面，也多是基於window組件的外殼，好比.net、c++寫的殼之類的，我用JavaFx寫過一個小東西，也相似與外殼，http很容易就解決，由於都支持。

     但Rpc呢，工做中與.net的人有過接觸，他們也能寫Rpc，但目前看出了thrift，hession、dubbo都不支持其餘語言。

          還一點須要注意，好比post，java的會把encode都作了，.net不處理就會出亂碼，沒經歷過的，看着本身沒問題的代碼會不明因此。

    微服務方面，目前比較流行rpc，rpc在7層中屬於第四層應用層，

     在代碼上的特色是一個接口方法，再也不去拼xml，json等數據格式。

     我用過的rpc有hession、thirft、dubbo，目前知道的就thirft是支持跨語言的。

     用dubbo的時候，沒能接觸生產環境，關於生產環境的dubbomonitor只是瞭解了一下，能確認的一點是dubbo目前只有java語言。

     thirft，經過官方提供的jar包和結構文件去生成代碼，我記得有好幾種。

    4.易於開發

    首先須要提供各類工具，和接入中間件client的基礎framework，還要包含配置文件處理，定時任務等。

    提供代碼生成器，其中，要將dao、service 獨立分開，這是惟一一塊對不一樣依賴影響最小的。dao須要掃數據庫，生成mybaties或者hibernate代碼。

    client、remote層，若是是傳統分佈式，這能夠是個springMVC之類的web層了。若是是微服務，這裏就是個要去服務中心註冊的服務了，至於轉http，還須要單獨的gateway。

     基本的增刪改查頁面，這個頁面應該是屬於後臺管理的，好比字典服務，生成頁面後能夠作增刪改查的操做。這裏也許須要shiro管理下權限

     全部結構基於maven parent module結構

     提供不一樣的測試環境

     提供 部署腳本 （玩分佈式的時候，這種shell腳本寫過不少次了，下載代碼、編譯、mv到tomcat下，重啓tomcat）

               

           以上只是隨筆寫寫，不在白板上去看，光憑想的話，不少東西還沒寫出來