技術雷達：關于技術趨勢的分析報告
By TWInsights
就在剛剛過去的 2015 年 11 月份，ThoughtWorks 又發布了最新一版的技術雷達。技術雷達是什么，來源以及如何運用，可以參考 Neal Ford 的一篇文章《Build Your Own Technology Radar》【中文翻譯】，這里就不再贅述。在本期的技術雷達中，提出了四個最新的技術動態，分別為：“Docker 引爆容器生態系統”、“微服務及相關工具受到追捧”、“JavaScript 工具正在趨于平穩”、“安全是每一個人的問題”。本文就主要圍繞這四個最新的技術動態，闡述一下筆者個人的理解和分析。
Docker 引爆容器生態系統
Docker 現在非常火，作為一個開源的應用容器引擎，它的出現讓容器技術的使用和管理變得非常簡單，也促使更多的人開始關注和意識到容器技術的真正價值和威力。由于其基于 LXC 的輕量級虛擬化技術，相比于 KVM 之類傳統的虛擬機技術最明顯的特點就是啟動快，資源利用率高。啟動一個容器只需要幾秒鐘，在一臺普通的 PC 上甚至可以啟動成百上千的容器，這都是傳統虛擬機技術很難做到的。目前容器技術已經被廣泛應用在軟件開發的各個階段各個領域，例如用于管理開發環境、用于測試、構建項目和實施持續集成，當然也可以作為傳統云平臺虛擬化的替代方案，實現更為輕量更具彈性的云計算平臺。
雖然上文提到的這些應用場景都是非常有價值的，但還不能體現 Docker 或是說容器技術如此火爆的原因。我們知道 Container 通常翻譯為容器，但是還有另一個翻譯就是集裝箱，集裝箱被很多人稱為是 21 世紀最偉大的發明之一，它的發明和廣泛使用甚至改變了世界的貨物運輸體系，促進了經濟的全球化發展，《集裝箱改變世界》這本書就是講述了集裝箱是如何改變世界的。而我們現在所提的容器技術和 Docker，是不是也在致力于改變軟件的世界，改變我們開發、測試、構建、部署、運維所有這些的現有方式呢？我覺得是有可能的，因為無論是集裝箱還是容器技術都為我們帶來了兩個重要的好處：一致性和隔離。
我們知道一個產品是否可以正常提供服務，只去確保軟件本身沒有問題是遠遠不夠的，需要同時保證軟件、基礎設施（例如硬件、操作系統和運行環境）以及配置的正確性和可靠性。而傳統的軟件開發方式，對于這三個方面的管理是分離的，再加上三者之間錯綜復雜的關系，就造成了我們常常掛在嘴邊的“環境問題”。但是通過使用容器技術，我們如果將軟件、基礎設施和配置作為一個整體使用容器進行封裝，產生一個個已經同時包含了軟件以及其運行環境的經過嚴格測試檢驗的“包”。這樣當部署“包”的時候就不需要再考慮環境的問題，也不需要關心現在部署的是一個 Web 服務還是一個數據庫服務，要做的只是把一個個容器標準化地安裝到指定的容器引擎即可。
可能正是大家都看到了容器技術以及 Docker 對于軟件開發各個領域正在帶來的改變，容器技術的生態系統也在經歷著一個快速發展的階段，涉及到開發輔助、集群管理、服務編排、內容發現、云平臺搭建等各種工具框架都一一呈現在我們面前，其中像 Google 和 Amazon 這樣的巨頭也都在第一時間發布了各自與容器相關的服務和框架。
微服務及相關工具受到追捧
如果大家關注 Docker，也肯定會經常聽到一種與之相關的架構，也就是微服務架構：
“微服務架構是一種架構模式，它提倡將單一應用程序劃分成一組小的服務，服務之間互相協調、互相配合，為用戶提供最終價值。每個服務運行在其獨立的進程中，服務與服務間采用輕量級的通信機制互相溝通（通常是基于 HTTP 協議的 RESTful API）。每個服務都圍繞著具體業務進行構建，并且能夠被獨立的部署到生產環境、類生產環境等。另外，應當盡量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建。”
這是 Martin Fowler 給出的對于微服務架構的定義，其中提到了微服務架構的四個特點：
- 將單一的應用程序劃分成一組小的服務
- 每個服務運行在其獨立的進程中
- 輕量級的通信機制
- 獨立的部署到生產環境
我看過很多非常成功的公司在分享其系統架構演進歷程時，往往最后都會落腳于服務拆分和業務服務化。其實這也不算是什么新的概念了，幾年前流行的 SOA 面向服務架構就已經為我們描繪了一個服務化架構的美好前景。那為什么又提出了一種新的微服務架構呢？對于這個問題 Martin Fowler 在他的那篇《Microservices》也給出了他的回答。簡要來說就是雖然這兩種技術都是以服務化和組件化為目標，但是架構理念和技術策略上有太多的不同。例如上邊提到的微服務架構的主要特點以及其倡導的演進式架構設計，去中心化的架構風格，采用輕量化通信機制，強調獨立部署等都是與 SOA 所提倡的技術和思路有很大區別。微服務架構也更契合現代的技術發展趨勢，例如 RESTful API 的流行，嵌入式應用服務器的應用，持續集成、持續交付的普及，容器技術爆發，組件化的趨勢，云平臺的發展等。
在引入微服務架構前，系統往往是以一個大的單體應用的形式存在的。此時任何功能的修改都需要重新構建部署整個應用，并且當需要水平擴展時也只能通過擴展整個應用的方式進行，無法做更細粒度的調度和控制。而當切換成微服務架構后，單一功能的修改只需要重新構建部署相應地服務即可，其他服務并不會受到影響。如果某個服務需要水平擴展時，我們也只需要擴展此服務即可。由此可見，微服務架構相比于傳統的單體應用架構，可以極大的提高我們的資源利用效率和系統彈性。再加上通過服務化我們可以更容易的以組件的方式組合和重用現有服務，快速地構建出新的服務，使企業和產品更具競爭力。
微服務架構還有很多其他的好處：例如我們可以為不同的服務使用異構的技術架構，用最適合的技術解決最適合的業務問題（例如在某些服務中使用關系型數據庫，而在某些服務中使用 NoSQL 數據庫）；相對于單體應用因為每個服務都更小更簡單，所以維護難度和成本也會比傳統的大的單體應用要低得多；還有根據康威定律，這種新的服務架構甚至會改變我們軟件開發的組織方式向小而精的多功能自組織團隊和全棧式演進，前段、后端、運維、DBA 這種角色劃分方式也許也會因此而成為歷史。
微服務架構之所以經常會和容器技術一起被提及，是因為容器技術為微服務架構提供了一個非常匹配的基礎設施，從而可以將這種架構的威力最大化的激發出來。設想一下，假如我們有一個產品采用微服務架構，并將每類服務及其運行環境打包為容器，部署于像 AWS ECS 這類彈性容器服務里。就可以實現通過實時監控每類服務的負載情況，通過自動化的方式快速按需對每類服務基于容器技術進行快速高效的水平擴展或是撤銷，這樣我們的架構就是一個高度自動化、高彈性、高資源利用率的應用架構，相比于傳統的單體應用也將具備很大的競爭優勢。
有得必有失，微服務架構有著這么多的好處，但同樣也會引入一些新問題，最直接的就是分布式本身所引入的復雜性。例如如何保證服務間的契約，如何快速開發服務，如何保證輕量級通訊協議的可靠性等等。對于這些問題也有著相對應的解決方案，本期雷達就推薦了很多的工具和技術來輔助進行微服務架構下的軟件開發。
JavaScript 工具正在趨于平穩
如果大家關注往期的技術雷達，肯定可以感受到 JavaScript 的火爆程度。例如在 2014 年 1 月刊就提出了“JavaScript 戰車一往無前”，以及在 2014 年 7 月刊又提出了“JavaScript 大爆發，框架遍地開花，創新目不暇接”的最新動態。JavaScript 如今繼續保持著它強勁的勢頭，但是我們也能感覺到無論是社區還是我們自己團隊，大家在經歷過暴風雨的波瀾后，慢慢平靜下來，無論對于 JavaScript 的框架、工具還是一些最佳實踐上的認同也在慢慢的趨于一致。
ECMAScript 2015 目前在雷達上已經被列入了“采用”的階段。意味著已經沒有什么障礙和疑慮再阻止我們使用這個最新的規范，在 JavaScript 平臺上享受一個現代語言為我們帶來的簡潔、便利和強大。在構建工具和包管理工具的選擇上，NPM 和 Webpack 也逐漸成為越來越多人選擇的對象。
而對于前端框架的選擇上，React.js 熱的發燙，它喊著“Rethinking Best Practices”的口號，舉著組件化的大旗，讓每個人目瞪口呆之后，又開始重新審視我們的前端開發實踐。如果說容器化實現了基礎設施的組件化，而微服務架構提供了架構層面的組件化方案，那 ReactJS 就把組件化帶到了前端開發……哦對了，還有移動開發領域。
安全是每一個人的問題
安全越來越受到大家的重視，從“SSL 心臟滴血”到“Xcode Ghost”，再到時常出現的用戶（商業）隱私信息泄露，釣魚詐騙，惡性攻擊等安全事件。讓我們越來越切身地感受到安全對于企業和個人的重要性。并且隨著互聯網和軟件行業的高速發展，安全形勢也變得越來越嚴峻：從硬件安全到操作系統安全，從工具安全到依賴組件的安全， 從網絡安全到應用安全，從代碼安全到密碼安全。任何一個點的疏忽都可能為企業和個人帶來毀滅性的打擊和傷害。
與安全形勢變得越來越嚴峻形成鮮明對比的就是以往我們在產品設計和開發過程中對于安全無論是在意識上還是在使用的技術上都遠遠達不到要求。對于安全的關注更多的是以一種“看門人”的方式進行的，也就是在開發和設計過程中往往很少考慮安全的問題，僅僅靠上線前的一段很短的時間，通過一些工具掃描安全漏洞，然后集中修復的方式。這種方式往往讓團隊處于非常被動的處境，很容易遺漏安全問題，產生安全風險，或是根本沒有時間修復所有的安全問題就草率冒險上線。
而現在有越來越多的團隊將安全引入到開發的整個生命周期當中，作為一等公民來看待和重視，將安全作為軟件質量的一個重要組成部分。例如在軟件的早期就通過引入威脅建模（Threat Modeling）的方式為產品做整體的安全建模，并將建模成果以驗收說明的方式寫入用例文檔或是用戶故事中。而開發人員也會在實現每個功能時將對安全的關注作為設計和實現的一部分，并為安全編寫相關的自動化測試，納入持續集成系統中保持對于安全的持續驗證和關注。
關于安全，本期技術雷達也推薦了很多的工具和技術，涉及產品安全、代碼安全、密碼安全、網絡安全、操作系統安全等安全領域。借助于這些工具和理念，可以幫助我們構建出更加安全的產品和服務。
寫在最后
以上就是對于本期技術雷達中四個最新動態的一些理解和分析。除此之外，本期的技術雷達還包含了其他很多領域和工具，包括架構設計、大數據、DevOps、數據庫技術、持續交付、測試技術等等待你我去探索。
來自: insights.thoughtworkers.org