1.前言
Spring Cloud 現在比較流行，版本更新也是蠻快的，網上資料也是很多。很多參考網上資料就可以學到了。這里給個 http://blog.csdn.net/forezp/article/details/70148833
2.放棄
本來還想寫一篇Spring Cloud 入門環境搭建的博客, 后來想了想,還是算了,網上資料一大堆.這里就不寫了.
3.吹水
下面就簡單聊聊天,吹吹水算了
2018.01.18 筆記
公司網速不行，在進行Maven項目以來更新，偷偷寫一些經歷。
現在開始學spring cloud。回想自己學習JavaWeb的經歷吧，大學時代2013-2014年學了SSH框架(Struts+Spring+Hibernate),工作后2015-2016年，用了(SpringMVC+Spring+JDBC)開發了一個項目，2017年，用來(SpringMVC+Spring+Mybatis)框架開發一個項目。四年，眼看這JavaEE技術的變更，真是太快了，開發也變得越來越簡單。
想起剛開始用SSH框架時，班里好多人跟着老師，或者跟着網上的教程來配置環境都是不成功的，而且報錯也是奇奇怪怪的。好多人最后都是拿着一份可以運行的最簡單版本源碼，復制過去，改一下包名。哈哈哈。現在想想真是搞笑啊。
下面只做一些回憶，里面有些知識可能會記錯。
當年用SSH框架時，每配置一個bean都要在一個xml里面配置一個<bean>還要指定包名，一些參數等。那時候還沒有bean注解這種方式。然后工作后，要負責開發一個項目了，本來想沿用以前學的SSH框架，后來上網找了一些文章，做了簡單的對比。發現用SpringMVC會比Struts方便，就決定采用SpringMVC了。至於第一個項目，用原始最簡單的JDBC的原因，是那時候覺得Hibernate太麻煩，然后去配置mybatis，但是一直配置不成功。花了幾天都不行，然后就覺得算了，直接用JDBC，反正項目不大，內部項目，自己玩玩而已。
加上但是技術覺悟不高，JDBC連接，還是最原始的使用原生操作，每個請求一個Connect，創建Statement，然后處理完就關閉。連個數據庫連接池都沒有。性能特別差。但是這個內部的小項目，也就2-3個人在使用而已。完全沒有問題。雖然后面出現了一點點性能問題。但是多等幾秒就好了。也就不怎么管了。
線上出現過由於Connect沒有即時關閉，導致tcp timewait問題，也簡單的規避掉了，人生第一個用於實際生產線上的JavaWeb項目。就這樣成功的運行着1年多了。
前半年對該系統進行了重構，技術框架也使用上了SSM框架了。第一次使用，用起來也還是比較方便的，印象最深刻的是bean的注入。但是前期項目的一堆XML配置還是少不了，不過就是項目初始化配置一次就可以，同時沒有用Maven管理jar包，自己上網找jar包，然后放到lib目錄下。一切都是那么的原始。
項目也沒有進行什么單元測試。一套我看起來還算稍微復雜的系統，我自己寫代碼，自己簡單的跑一下流程，沒有經過任何專業的測試，然后就直接上線，直接使用。想想真是心大啊。如果出現問題，還真是麻煩。
小問題可以不斷，大問題絕對沒有。這個是我對我自己的要求。由於自己性格處事比較謹慎，加上有ACM競賽背景。我自認為在同領域，同級別的同事間我代碼實現能力是最快，出問題最少的人。
2018年，開始着手於新的項目，趁着微服務比較火，加上也挺適合公司用的，就准備在公司進行推廣。這個推廣應該難度不大，反正就我一個人，暫時也沒有其他人要合作，同時沒有歷史遺留的項目問題，可以一步到位直接上SpringCloud。
2018.02.08 筆記
系統采用微服務架構, 目前搭建XX雲平台基礎服務,目前計划的基礎服務有
1. XX開發者中心 (是對開發商進行統一管理,包含開發商認證,帳號分配,資源申請,固件上傳等)
2. 設備統一認證中心(是公司對每一台設備進行管理,包含profile燒寫及記錄,設備日志等功能)
3. 用戶統一認證中心(是對用戶進行管理,包含用戶手機注冊,管理,微信/QQ/微博等互聯,用戶社交互動,對設備進行控制等功能)
4. 第三方資源服務 (外部服務對接,微信服務器,客戶資源服務器,並對資源進行調度,流量控制管理)
5. 消息推送服務 (統一推送平台,推送到android/iOS手機平台,推送到微信公眾號,小程序,推送到Web,手機推送, 小機設備推送等)
6. MQTT通信服務 (所有物聯網產品,物物通信采用MQTT集群通信服務)
每個服務間的職責都是清晰分開管理.減少業務耦合度. 現在處於架構搭建初期,很多基礎設施和業務都不清晰,只能一步一步慢慢完善,爭取整個架構搭建起來,然后進行架構重新調整.
服務與服務間是免認證, 后面增加 全局認證服務, 統一對各個服務進行權限認證.
服務與服務間的數據共享, 通過緩存/關系型數據庫/消息隊列/分布式文件系統/阿里雲存儲
建立在各個基礎服務之上的有 全局配置中心,全局監控平台,全局調度平台,OAuth2.0權限認證,Eureka服務發現,服務熔斷機制等服務完善雲平台架構
依賴於各個基礎服務的是解決方案,具體項目.
項目初期,盡量防止過渡設計,大而全.初期盡量在滿足業務的情況下,慢慢迭代優化,任何系統都不可能一步到位.
快速建立原型是必須的,但是前期的服務分層和架構必須嚴格遵守,職責分明.