導語
喜歡踢球的同學一般知道這樣的一個段子，當年有好事的記者問風頭正盛的球王馬拉多納，在他進球中，哪個踢得最精彩？馬拉多納想了想就說：“一個吧”所以，努力追求“下一個”是一個普通球員到天才球員的必備品質，那麼在快速網際網路行業中同樣如此，每一次的技術更新變革也意味著無數個追求“下一個”的網際網路從事著的日日夜夜的辛勤勞動。

第一章 軟體架構演進
按照不同階段使用的軟體架構來排序：單體架構，垂直架構，服務化架構，微服務架構以及未來可能出現的無服務架構（ServiceLess）以及服務網格（Service Mesh）。
1.單體架構
單體架構在初創的小微企業比較常見，典型代表就是一個應用、一個數據庫、一個Web容器就可以跑起來，但現在實際的。
特點：
所有功能集中在一個專案工程中，所有的功能在一個war包中，然後部署到服務上，並且可以通過叢集來提高系統的效能瓶頸。
優點：
①部署實施簡單，可以保證專案快速上線。
②專案架構簡單，前期開發成本低，週期短。
缺點：
①全部功能整合在一個工程中，對於大型專案不易開發、擴充套件及維護。
②系統性能擴充套件只能通過擴充套件叢集結點，成本高。

2.垂直架構
每一個垂直模組屬於一個單一團隊，通過垂直拆分，原來的單體專案不至於無限擴大。在模組之間共享程式碼是嚴令禁止的。出現了影響力最大設計典範MVC模式，模型(model)－檢視(view)－控制器(controller),SSH框架是典型的MVC設計思想的應用框架。
特點：
垂直架構思想在於分層。
優點：
①隱藏下層的實現。下層為上層提供其所需的服務，但實現的過程，上層是無法知曉的。
②不同的專案可採用不同的技術。
③程式碼的複用性得到極大提高。
缺點：
①上下層級相互依賴，牽一髮而動全身。
②全部功能整合在一個工程中，對於大型專案不易開發、擴充套件及維護。

3.服務化架構
SOA代表面向服務的架構，將應用程式根據不同的職責劃分為不同的模組，不同的模組直接通過特定的協議和介面進行互動。這樣使整個系統切分成很多單個元件服務來完成請求，當流量過大時通過水平擴充套件相應的元件來支撐，所有的元件通過互動來滿足整體的業務需求。
特點：
在系統的角度，解決兩個核心的問題，程式的通訊問題以及服務化的構成。由於服務化架構使用的RPC通訊的方式，所以也被很多人稱為RPC框架,RPC是遠端呼叫，RPC是服務化架構的核心，在OSI網路通訊模型中，RPC跨越了傳輸層和應用層。RPC，WebService等通訊方式使得服務化的分散式基礎。
優點：
①將重複的功能抽取為服務，提高開發效率，提高系統的可重用性、可維護性。②採用ESB減少系統中的介面耦合。
缺點：
①抽取的服務的粒度過大，系統與服務之間耦合性高。
②系統與服務的界限模糊，不利於開發及維護。

軟體架構演進總結：單體架構是最早最行之有效的軟體架構，也是對以後的架構發展的基礎；在單體架構發展一段時間後，公司的業務量和業務層級開始需要更高的要求， 在這一階段單體架構的增加機器帶來提高瓶頸的功能越來越小，最後只能將系統分為不同的層級，每個層級有對應的職責，以提升效率；如果公司進一步的做大，垂直子系統會變的越來越多，系統和系統之間的呼叫就不能避免了，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，以便應用更快速度的響應多變的市場需求。

第二章 微服務架構
其實服務化架構已經可以解決大部分企業的需求了，程式之間可以通訊了，邏輯上服務也分離出來了，那麼我們為什麼要研究微服務呢？微服務架構是SOA架構思想的一種擴充套件，更加強調服務個體的獨立性、拆分粒度更小。

微服務的定義
將大型的複雜應用分解為多個小的微服務，每個微服務都圍繞著具體業務進行構建，各微服務可分散式獨立部署，且服務之間互相協調、互相配合，實現應用的快速迭代。

微服務的優點和缺點
優點：能夠獨立完成相應的服務，不再相互牽制。
缺點：微粒度越高，維護的成本越高。

微服務的價值
微服務的價值按照職位不同的角度來闡述的話，對於運維，開發人員，測試人員來說，是能提高工作效率的系統或者是工具；而對於CTO，技術管理者來說，微服務架構能夠解決部分管理問題，合理的微服務抽象和拆分對應合理的組織結構劃分，每個服務就變成一個獨立的小產品，運營這個產品就是組織主要目標，產品的價值決定部門的價值，產品使用者的多少決定組織價值的高低，這種類似市場化的管理方法是最能提供明確的指導性，戰略性。

服務化架構與微服務化架構對比
1.通訊方式對比
服務化架構採用的RPC通訊方式，而微服務架構採用的是REST的通訊方式。RPC通訊是基於TCP傳輸層協議的產物（7層協議中的第三層），但像很多對DUBBO二次開發的的框架同樣也支援HTTP，例如噹噹網的DUBBOX。RESTFUL通訊方式是基於HTTP應用層協議的產物。RPC是以動詞為中心的, REST是以名詞為中心的, 此處的動詞指的是一些方法, 名詞是指資。以動詞為中心,意味著,當你要需要加入新功能時,你必須要新增更多的動詞, 這時候伺服器端需要實現相應的動詞(方法), 客戶端需要知道這個新的動詞並進行呼叫。而以名詞為中心, 假使我請求的是 hostname/friends/, 無論這個URI對應的服務怎麼變化,客戶端是無需關注和更新的,而這種變化對客戶端也是透明的。

2.典型框架對比
DUBBO是SOA架構時代的產物，但國內技術人喜歡拿DUBBO和微服務架構SPRING CLOUD進行對比，是因為兩者都是服務治理非常優秀的開源框架。DUBBO系出名門，是2008年底在阿里內部開始規劃呼叫，2011開源的服務化治理的核心框架，2013年中途停止過，2017年9月份又重啟維護併發布了新版本並被廣泛應用於阿里巴巴集團的各成員站點。同時阿里雲也推出了企業級分散式應用服務EDAS，為DUBBO提供應用託管。SPRING CLOUD，從命名我們就可以知道，它是SPRING SOURCE的產物，SPRING社群的強大背書可以說是JAVA企業界最有影響力的組織了，而為其提供技術後盾是Netflix公司(https://netflix.github.io/)，在中國也叫網飛。Netflix也是非常有傳奇色彩的公司，最開始是線上影片租賃，後來開始自制劇，著名的紙牌屋就是出自網飛，去年還買下了白夜追凶的播放版權。就目前請看看來說，阿里的DUBBO知名度更高一些，一個可能這也與早年阿里就開源了DUBBO框架之外，另一個原因是不少科技公司的架構師或者是主程均出自阿里系習慣了阿里的內部框架。隨著技術的發展，大家可以關注兩個框架的發展情況。

3.框架選型
可以打個比方。SPRING CLOUD品牌機，DUBBO是組裝機；品牌機的相容性有保證，開機即用。組裝的機子更自由，選購自己心儀的CPU，記憶體條，硬碟等資源，但是需要一定技術能力去規劃組裝。但總的來說，微服務是未來發展的大趨勢，有意更換架構的企業可以儘早做好打算。

第三章 Spring Cloud與DevOps實戰
Spring Cloud
Spring Cloud是一系列框架的有序集合，它利用Spring Boot的開發便利性巧妙地簡化了分散式系統基礎設施的開發，如服務發現註冊、配置中心、訊息匯流排、負載均衡、斷路器、資料監控等，都可以用Spring Boot的開發風格做到一鍵啟動和部署。Spring 並沒有重複製造輪子，它只是將目前各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，通過Spring Boot風格進行再封裝、遮蔽掉了複雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分散式系統開發工具包。Spring Cloud是微服務最典型也是目前應用最廣泛的架構。

所有請求都統一通過 API 閘道器(Zuul)來訪問內部服務；閘道器接收到請求後，從註冊中心(Eureka)獲取可用服務；由Ribbon進行均衡負載後，分發到後端的具體例項；微服務之間通過Feign進行通訊處理業務；Hystrix負責處理服務超時熔斷；Turbine監控服務間的呼叫和熔斷相關指標。

CI/CD
CI持續整合，CD持續交付，通常會採用一些軟體如Jenkins、TeamCity等來輔助專案流程。CI/CD能夠與Git SVN等程式碼管理倉庫整合，幫助使用者實現自動化任務。CI/CD是DevOps中最重要也是最典型的實際應用。

Spring cloud與DevOps結合
Spring cloud與DevOps不是先有雞還是先有蛋的問題，而是相互利好的關係。DevOps就是直擊Spring cloud的痛點，把最複雜的分散式的服務，進行高效持續的生產。使用Spring cloud，第一步是要構建一個一體化的DevOps平臺，試想如果不使用DevOps做微服務的話，整個環境會變得非常的亂、非常的糟糕，Spring cloud會給你的整個開發、測試和運維增加很多成本，反而是得不償失了。所以第一步我們是提高DevOps的能力，能夠把它的開發、部署和維護進行很完美的結合，才可以說我們真正能夠享受到Spring cloud框架的福利。

技術流程（手動打包）
1.Jenkins從倉庫中手動拉取最新程式碼。
2.通過Jenkins的自帶外掛打包編譯程式碼。
3.進行單元測試。
4.build構建最新的容器映象。
5.push映象到映象倉庫中去。
6.使用K8S或者docker-compose等容器編排工具進行專案的啟動。

第四章 思考
中小企業新技術的選擇思考
1.永遠不要優先考慮效能問題，等到有效能問題，使用負載均衡。等到負載均衡搞不定時，公司也大了，就說融資上市的事情了，那就有新的技術架構技術方案代替原來的。
2.優先考慮的是文件/社群/可維護性。
3.優先選擇硬通貨，一旦有問題不僅僅是你一個人有問題，可以去Stack Overflow找答案；可以參考swarm和K8S的情況。

微服務的可實施性思考
我的總結觀點是：不要為了追求技術而追求技術。穩定而有效的結果才是我們的最求，例如我維護過做遊戲的日本客戶，到現在都還在使用Windows Server 2013系統。
1.團隊的技術人員是否已經具備相關技術基礎。包含了對微服務的理解，DevOps的掌握等等都需要過硬的技術實力。
2.公司業務是否適合進行微服務化改造，並不是所有的平臺都適合進行微服務化改造，比如：傳統行業有很多複雜垂直的業務系統。而且要涉及到整個業務的資料庫的分表分庫，重新統一服務介面，最後還要規劃具體的容器實施部署。
3.Spring Cloud 生態的技術有很多，並不是每一種技術方案都需要用上，適合自己的才是最好的。

運維行業的思考
新的技術發展到現在，給我最深的感觸就是基礎性的技術支援越來越被隱藏，更多的是強調自身業務快速實現和拓展。國外像Netflix和亞馬遜是壓根就沒有運維這樣的角色，運維的事情都是由開發工程師來完成，他們的職位名稱是SDE(Software Develop Engineer)，所以他們也被戲稱為Someone Do Everything。所以，運維轉型不是一句嚇唬人的話，真的已經在我們身邊發生了。

總結
技術變革的根本原因是業務發展的瓶頸與突破，技術能力決定業務能力的寬度，業務能力決定公司的長度；當技術能力達到一定高度的時候，可以試著調整自己的思考角度，從產品，從業務發展來考慮，又可以看到不一樣的風景。