首先技術并沒有好壞之分，只能說一種技術在特定場景會優于另一種技術。
首先uread優讀（http://aiuread.com/）作為一個還處于起步階段的團隊，那么沒辦法造出像大企業他們那種自動化運維平臺，真實情況是連用OpenStack來管理應用都是一種高難度活。
第一階段，單體應用，純人力部署
團隊一開始，反正后端就一個系統，然后又是用git作為團隊內部的協作工具，部署理所當然是直接每次發布新版本，直接執行git pull，然后執行一個封裝好kill進程，重啟進程的shell腳本，接著更新版本流程完成。
第二階段，服務拆分，交互遇到問題
隨著功能越來越多，后端前端的同學也越來越多，以前一個工程囊括整個項目的做法的弊端開始顯露出來。首先，由于工程膨脹，要一位新來的同學看懂整個工程會變得非常困難，并且提交代碼的時候沖突會非常嚴重。現在微服務不是很流行么，所以團隊也考慮是不是拆開成微服務呢。
一開始，已經研發的部分也不可能推倒拆分。所以，決定新增的大功能拆成獨立工程。當拆開獨立項目的時候，第一個出現的問題并不是部署問題，因為多幾個應用，部署工作量其實也不會是人力不能承受。
拆分應用之后，出現的主要問題是，這些獨立的應用如何交互。也許你會說是不是設計不合理呀，微服務單向調用那會有什么問題。且慢，當你實踐過，你就不會說就這么簡單。
微服務交互，主要我們嘗試過基于http協議的交互，對于耗時處理采用回調方式。由于業務原因，有大量耗時操作，所以一個功能就要寫很多個微服務。
由于為了每位同學都只關注自己的模塊，所以數據入庫也是自己處理自己的部分，結果就是一個業務交互就需要4個微服務。
基于http協議交互，一個問題是，每一個微服務都有一個ip和端口。當我們的微服務數量越來越多的時候，配置里面的地址信息也越來越不好維護，特別涉及服務地址變動的時候。這個時候，基于消息中間件的微服務交互方式進入我們的研發之中。
第三階段，基于消息中間件的微服務交互
當我們引入了rabbitmq這個消息中間件，代替了http請求通訊。我們再也不怕微服務地址變更這種問題，在微服務擴容的時候，我們也可以無縫處理。但是我們最后還是棄用了這種交互方式，為什么呢？因為我們忘記了我們只是一個小團隊，引入越多的技術，對于我們經驗不太豐富的同學來說，簡直就是災難。
那么，我們只能用回基于http的交互方式，但是微服務地址維護這個大問題就需要一個途徑解決掉。
第四階段，微服務基于sdk交互
這個時候，我們編寫某個微服務的同學，就要提供調用該微服務的sdk，那么對于調用該服務的同學來說，只需要引入該sdk即可，無論微服務如何變，更新sdk即可（sdk的函數必須是兼容升級）。
第五階段，服務發現系統
雖然，我們基于sdk來調用微服務，但是一個問題來了。我們微服務每一次擴容，就要更新sdk里面的地址。這個對于我們彈性部署來說是一個嚴重問題。
這個時候，sdk動態獲取一個微服務真實地址就十分重要了。所以我們簡單的造了一套系統，一個服務名字隨機獲取一個微服務真實地址。架構圖如下：
第六階段，自動化部署
微服務的交互這個最主要問題解決之后，免去人工執行shell腳本部署應用提上了日程。
原始階段，把創建環境拉取代碼封裝成一個shell腳本。打包環境采用docker鏡像，為什么用docker呢，因為docker打包環境寫一個Dockerfile就成了，并且最新版的docker可以用docker swarm把容器分布到多臺機器。
每次更新，手動執行shell工作量還是有點大，好在有git鉤子，每一次某個分支提交代碼后觸發腳本自動部署。
第七階段，應用日志問題
由于階段六，我們應用存在docker里面，日志也在容器里面，并且分散在多臺服務器。日志收集是一個問題，主流的ELK這一套還是同樣的問題，太重了，引入對團隊是一個負擔。所以一個折中的辦法，由于我們用的框架都有一個同一個錯誤捕捉函數，當我們捕抓到錯誤的時候，我們就把信息post到通知機器人鉤子，這些程序會把信息發到我們的協同工作軟件，所以我們會第一時間知道哪個請求觸發了什么錯誤。
接下來
當然是要做彈性擴容了，只是當前還沒有需要大規模擴容的場景，那就先不造這輪子。
