最近一直在針對springcloud框架做專案，從中踩了不少的坑，也漸漸梳理出了一些內容，由於springcloud作為乙個全家桶，其中東西太多，所以這時候就要有所取捨，這裡就想把自己比較常用元件及架構推薦上來。本文基於springboot 1.5.7和spirngcloud dalston.sr5。
針對這個架構圖我分層介紹一下：
1、是web伺服器的選型，這個我選擇的是nginx+keepalived，haproxy也是乙個選擇，但是haproxy在反向**處理跨域訪問的時候問題很多。所以我們nginx有些地方做了keep-alive模式處理，減少了三次握手的次數，提高了連線效率。keepalived做nginx的負載，虛擬乙個vip對外，兩個nginx做高可用，nginx本身反向**zuul集群。
2、api gateway，這裡的zuul很多人詬病，說是速度慢推薦直接用nginx，這裡我還是推薦使用zuul的，畢竟zuul含有***和反向**，在許可權管理、單點登入、使用者認證時候還是很有用的，而且zuul自帶ribbon負載均衡，如果你直接用nginx，還需要單獨做乙個feign或者ribbon層，用來做業務集群的負載層，畢竟直接把介面暴露給web伺服器太危險了。這裡zuul帶有ribbon負載均衡和hystrix斷路器，直接反向**serviceid就可以**整個集群了。
3、業務集群，這一層我有些專案是分兩層的，就是上面加了乙個負載層，下面是從service開始的，底層只是單純的介面，controller是單獨一層由feign實現，然後內部不同業務服務介面互調，直接呼叫controller層，只能說效果一般，多了一次tcp連線。所以我推薦合併起來，因為做過spring cloud專案的都知道，feign是含有ribbon的，而zuul也含有ribbon，這樣的話zuul呼叫服務集群，和服務集群間介面的互調都是高可用的，保證了通訊的穩定性。hystrix還是要有的，沒有斷路器很難實現服務降級，會出現大量請求傳送到不可用的節點。當然service是可以改造的，如果改造成rpc方式，那服務之間互調又是另外一種情況了，那就要做成負載池和介面服務池的形式了，負載池呼叫介面池，介面池互相rpc呼叫，feign client只是通過實現介面達到了仿rpc的形式，不過速度表現還是不錯的。
4、redis快取池，這個用來做session共享，分布式系統session共享是乙個大問題。同時呢，redis做二級快取對降低整個服務的響應時間，並且減少資料庫的訪問次數是很有幫助的。當然redis cluster還是redis sentinel自己選擇。
5、eurake註冊中心這個高可用集群，這裡有很多細節，比如多久重新整理列表一次，多久監測心跳什麼的，都很重要。
6、spring admin，這個是很推薦的，這個功能很強大，可以整合turbine斷路器監控器，而且可以定義所有類的log等級，不用單獨去配置，還可以檢視本地log日誌檔案，監控不同服務的機器引數及效能，非常強大。它加上elk動態日誌收集系統，對於專案運維非常方便。
7、zipkin，這個有兩種方式，直接用它自己的功能介面檢視方式，或者用stream流的方式，由elk動態日誌系統收集。但是我必須要說，這個對系統的效能損害非常大，因為鏈路追蹤的時候會造成響應等待，而且等待時間非常長接近1秒，這在生產環境是不能忍受的，所以生產環境最好關掉，有問題除錯的時候再開啟。
8、訊息佇列，這個必須的，分布式系統不可能所有場景都滿足強一致性，這裡只能由訊息佇列來作為緩衝，這裡我用的是kafka。
9、分布式事物，我認為這是分布式最困難的，因為不同的業務集群都對應自己的資料庫，互相資料庫不是互通的，互相服務呼叫只能是相互介面，有些甚至是異地的，這樣造成的結果就是網路延遲造成的請求等待，網路抖動造成的資料丟失，這些都是很可怕的問題，所以必須要處理分布式事物。我推薦的是利用訊息佇列，採取二階段提交協議配合事物補償機制，具體的實現需要結合業務，這裡篇幅有限就不展開說了。
10、config配置中心，這是很有必要的，因為服務太多配置檔案太多，沒有這個很難運維。這個一般利用訊息佇列建立乙個spring cloud bus，由git儲存配置檔案，利用bus匯流排動態更新配置檔案資訊。
11、實時分布式日誌系統，logstash收集本地的log檔案流，傳輸給elasticsearch，logstash有兩種方式，1、是每一台機器啟動乙個logstash服務，讀取本地的日誌檔案，生成流傳給elasticsearch。2、logback引入logstash包，然後直接生產json流傳給乙個中心的logstash伺服器，它再傳給elasticsearch。elasticsearch再將流傳給kibana，動態檢視日誌，甚至zipkin的流也可以直接傳給elasticsearch。這個配合spring admin，乙個檢視動態日誌，乙個檢視本地日誌，同時還能遠端管理不同類的日誌級別，對整合和運維非常有利。
最後要說說，spring cloud的很多東西都比較精確，比如斷路器觸發時間、事物補償時間、http響應時間等，這些都需要好好的設計，而且可以優化的點非常多。比如：http通訊可以使用okhttp，jvm優化，nio模式，資料連線池等等，都可以很大的提高效能。
SpringCloud架構設計
最近一直在針對springcloud框架做專案，從中踩了不少的坑，也漸漸梳理出了一些內容，由於springcloud作為乙個全家桶，其中東西太多，所以這時候就要有所取捨，這裡就想把自己比較常用元件及架構推薦上來。本文基於springboot 1.5.7和spirngcloud dalston.sr5...
Spring Cloud 2 軟體架構設計
分層架構是運用最為廣泛的架構模式，幾乎每個軟體系統都需要經過層來隔離不同的關注點，以此應對不同需求的變化，使得這種變化可以獨立進行 各個層 甚至同一層中的各個元件都會以不同速率發生變化。這裡所謂的 以不同速率發生變化 其實就是引起變化的原因各有不同，這正好是單一職責原則 single respons...
salesforce 架構設計 從架構設計到架構師
因為碎片化的時間多了，所以開始刷起某乎了，關注了架構相關的板塊，也順手回答了一些問題。發現有很多同道中人正在經歷著我前兩年經歷的階段，對於做架構沒有相對具象的一些理解，更沒有系統化的認識。所以把最近回答的一些內容整理一下，權當記錄，留給3年後的自己 按慣例，容許我裝x開頭 一 架構的定義 在軟體開發...