最近一直在針對SpringCloud架構做項目，從中踩了不少的坑，也漸漸梳理出了一些内容，由于SpringCloud作為一個全家桶，其中東西太多，是以這時候就要有所取舍，這裡就想把自己比較常用元件及架構推薦上來。
針對這個架構圖我分層介紹一下：
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的形式，不過速度表現還是不錯的。
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模式，資料連接配接池等等，都可以很大的提高性能。
還有一個docker問題，很多人說不用docker就不算微服務。其實我個人意見，spring cloud本身就是微服務的，隻需要jdk環境即可。編寫dockerfile也無非是內建jdk、添加jar包、執行jar而已，或者用docker compose，将多個不同服務的image組合run成容器而已。但是帶來的問題很多，比如通訊問題、伺服器性能損耗問題、容器程序崩潰問題，當然如果你有一套成熟的基于k8s的容器管理平台，這個是沒問題的，如果沒有可能就要斟酌了。而spring cloud本身就是微服務分布式的架構，是以個人還是推薦直接機器部署的，當然好的DevOps工具将會友善很多。需要JAVASpring Cloud大型企業分布式微服務雲建構的B2B2C電子商務平台源碼請加企鵝求求:三五三六二四七二五九
![Java小案例——随機數猜測随機數猜測[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)