技術雷達 : 關於技術趨勢的分析報告
就在剛剛過去的2015年11月份，ThoughtWorks又釋出了最新一版的技術雷達。技術雷達是什麼，來源以及如何運用，可以參考Neal Ford的一篇文章《Build Your Own Technology Radar》【中文翻譯】，這裡就不再贅述。在本期的技術雷達中，提出了四個最新的技術動態，分別為：“Docker引爆容器生態系統”、“微服務及相關工具受到追捧”、“JavaScript工具正在趨於平穩”、“安全是每一個人的問題”。本文就主要圍繞這四個最新的技術動態，闡述一下筆者個人的理解和分析。
Docker引爆容器生態系統
Docker現在非常火，作為一個開源的應用容器引擎，它的出現讓容器技術的使用和管理變得非常簡單，也促使更多的人開始關注和意識到容器技術的真正價值和威力。由於其基於LXC的輕量級虛擬化技術，相比於KVM之類傳統的虛擬機器技術最明顯的特點就是啟動快，資源利用率高。啟動一個容器只需要幾秒鐘，在一臺普通的PC上甚至可以啟動成百上千的容器，這都是傳統虛擬機器技術很難做到的。目前容器技術已經被廣泛應用在軟體開發的各個階段各個領域，例如用於管理開發環境、用於測試、構建專案和實施持續整合，當然也可以作為傳統雲平臺虛擬化的替代方案，實現更為輕量更具彈性的雲端計算平臺。
我們知道一個產品是否可以正常提供服務，只去確保軟體本身沒有問題是遠遠不夠的，需要同時保證軟體、基礎設施（例如硬體、作業系統和執行環境）以及配置的正確性和可靠性。而傳統的軟體開發方式，對於這三個方面的管理是分離的，再加上三者之間錯綜複雜的關係，就造成了我們常常掛在嘴邊的“環境問題”。但是通過使用容器技術，我們如果將軟體、基礎設施和配置作為一個整體使用容器進行封裝，產生一個個已經同時包含了軟體以及其執行環境的經過嚴格測試檢驗的“包”。這樣當部署“包”的時候就不需要再考慮環境的問題，也不需要關心現在部署的是一個Web服務還是一個數據庫服務，要做的只是把一個個容器標準化地安裝到指定的容器引擎即可。
可能正是大家都看到了容器技術以及Docker對於軟體開發各個領域正在帶來的改變，容器技術的生態系統也在經歷著一個快速發展的階段，涉及到開發輔助、叢集管理、服務編排、內容發現、雲平臺搭建等各種工具框架都一一呈現在我們面前，其中像Google和Amazon這樣的巨頭也都在第一時間釋出了各自與容器相關的服務和框架。
微服務及相關工具受到追捧
如果大家關注Docker，也肯定會經常聽到一種與之相關的架構，也就是微服務架構：
“微服務架構是一種架構模式，它提倡將單一應用程式劃分成一組小的服務，服務之間互相協調、互相配合，為使用者提供最終價值。每個服務執行在其獨立的程序中，服務與服務間採用輕量級的通訊機制互相溝通（通常是基於HTTP協議的RESTful API）。每個服務都圍繞著具體業務進行構建，並且能夠被獨立的部署到生產環境、類生產環境等。另外，應當儘量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建。”
這是Martin Fowler給出的對於微服務架構的定義，其中提到了微服務架構的四個特點：
- 將單一的應用程式劃分成一組小的服務
- 每個服務執行在其獨立的程序中
- 輕量級的通訊機制
- 獨立的部署到生產環境
我看過很多非常成功的公司在分享其系統架構演進歷程時，往往最後都會落腳於服務拆分和業務服務化。其實這也不算是什麼新的概念了，幾年前流行的SOA面向服務架構就已經為我們描繪了一個服務化架構的美好前景。那為什麼又提出了一種新的微服務架構呢？對於這個問題Martin Fowler在他的那篇《Microservices》也給出了他的回答。簡要來說就是雖然這兩種技術都是以服務化和元件化為目標，但是架構理念和技術策略上有太多的不同。例如上邊提到的微服務架構的主要特點以及其倡導的演進式架構設計，去中心化的架構風格，採用輕量化通訊機制，強調獨立部署等都是與SOA所提倡的技術和思路有很大區別。微服務架構也更契合現代的技術發展趨勢，例如RESTful API的流行，嵌入式應用伺服器的應用，持續整合、持續交付的普及，容器技術爆發，元件化的趨勢，雲平臺的發展等。
在引入微服務架構前，系統往往是以一個大的單體應用的形式存在的。此時任何功能的修改都需要重新構建部署整個應用，並且當需要水平擴充套件時也只能通過擴充套件整個應用的方式進行，無法做更細粒度的排程和控制。而當切換成微服務架構後，單一功能的修改只需要重新構建部署相應地服務即可，其他服務並不會受到影響。如果某個服務需要水平擴充套件時，我們也只需要擴充套件此服務即可。由此可見，微服務架構相比於傳統的單體應用架構，可以極大的提高我們的資源利用效率和系統彈性。再加上通過服務化我們可以更容易的以元件的方式組合和重用現有服務，快速地構建出新的服務，使企業和產品更具競爭力。
微服務架構還有很多其他的好處：例如我們可以為不同的服務使用異構的技術架構，用最適合的技術解決最適合的業務問題（例如在某些服務中使用關係型資料庫，而在某些服務中使用NoSQL資料庫）；相對於單體應用因為每個服務都更小更簡單，所以維護難度和成本也會比傳統的大的單體應用要低得多；還有根據康威定律，這種新的服務架構甚至會改變我們軟體開發的組織方式向小而精的多功能自組織團隊和全棧式演進，前段、後端、運維、DBA這種角色劃分方式也許也會因此而成為歷史。
微服務架構之所以經常會和容器技術一起被提及，是因為容器技術為微服務架構提供了一個非常匹配的基礎設施，從而可以將這種架構的威力最大化的激發出來。設想一下，假如我們有一個產品採用微服務架構，並將每類服務及其執行環境打包為容器，部署於像AWS ECS這類彈性容器服務裡。就可以實現通過實時監控每類服務的負載情況，通過自動化的方式快速按需對每類服務基於容器技術進行快速高效的水平擴充套件或是撤銷，這樣我們的架構就是一個高度自動化、高彈性、高資源利用率的應用架構，相比於傳統的單體應用也將具備很大的競爭優勢。
有得必有失，微服務架構有著這麼多的好處，但同樣也會引入一些新問題，最直接的就是分散式本身所引入的複雜性。例如如何保證服務間的契約，如何快速開發服務，如何保證輕量級通訊協議的可靠性等等。對於這些問題也有著相對應的解決方案，本期雷達就推薦了很多的工具和技術來輔助進行微服務架構下的軟體開發。