大型電商系統架構的微服務與敏捷開發實踐方法教程

大型電商系統架構的微服務與敏捷開發實踐方法教程，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

       Java電商系統的架構10年前還是SSH的天下，那時候基本都是采用Strurt + Spring + Hibernate/Mybatis這些當時當時最流行技術來構建。但是這個世界沒有一招鮮的事情， IT技術的發展比其他行業都要快， 新舊知識的迭代特別快，很多流行的技術就只是流行一段時間又快速的凋零，導致系統要不斷的更新其技術體系以保證其技術的先進性。由于舊知識很快要過保質期，導致很多IT人員要不斷的積累和學習新的知識，稍有松懈馬上就會遇到中年危機。 中年危機的本質是由于身體、家庭的原因導致學習新知識的速度和意愿都下降了， 知識積累的速度和范圍跟不上時代的發展，所以很多IT從業人員在35-40歲就要被迫離開這個行業了。這個是很殘酷的話題，但是正因為這個行業發展比較快，所以才給新人帶來各種機會，給小公司帶來彎道超車并成功的可能，只要抓住一個點不斷的發力去打磨，就算是大公司再多的資本也是無法應對，因為那個突破點太多了，不可能每個點都能面面俱到。資源投入到那個方向和執行力如何決定了一家公司的高度。

      以上說明了信息科技這個行業，變化是唯一不變的真理。我們能做的只是不斷的擁抱變化， 想要一勞永逸、一夜暴富的心態還是要不得。

      言歸正傳，在互聯網產業飛速變革的今天，系統的架構也要不斷的發展，才能發揮更好的開發效率。一般的系統會經歷了以下幾個階段的架構變化。

1. 標準的SSH的單體應用， 一個war包打天下，所有的功能都放在一個應用里，這種做法部署和集群部署都比較容易，成本低；

2. 按功能垂直劃分的多個子應用，多個war包一起部署，組成一個完整的系統。這種做法靈活度有所提高， 可以按功能來劃分開發小組；

3. 微服務系統，目前比較流行的是采用spring cloud/dubbo這些微服務框架做前后端的分離開發模式。橫向把前端和后端從人員架構上分離開來，用于減少對人員的綜合素質要求。現在前端的技術發展日新月異，已經很難做到一個人能做到前后端通吃，前端包括IOS、Android、WAP、各種小程序等， 所有前端都要共用同一套后臺接口，后端的開發同事只要提供RESTFUL風格的接口，通過swagger等技術手段把接口暴露給前端調用即可。

       從一個普通SSH/SSM架構的系統升級上來到底是spring cloud更合適還是dubbo更合適呢？ 因為dubbo曾經停止更新過一段時間，因此目前收到的反饋是大多數公司都會優先選擇spring cloud，但是在實踐的過程又發現在原有的系統上升級上來的話采用dubbo會更容易修改，但是新系統的話還是會優先選擇采用spring cloud，因為spring cloud的生態更加完善。但是阿里最近又在重新維護dubbo，并且新開源了一套叫spring cloud alibaba的開源微服務產品，Spring Cloud Alibaba和Spring Cloud的關系是怎么樣的呢？ Spring Cloud Alibaba（以下簡稱SCA）和Spring Cloud Netflix（以下簡稱SCN）一樣，都是Spring Cloud規范的一套實現。看一下他們之間的差異：

       可見這2套系統的原理都一樣的， 阿里巴巴的版本想要通過利用spring cloud的生態來拉攏spring cloud的程序員，有點師夷長技以制夷的味道。這個版本提供了一個比較好用的配置中心、注冊中心Nacos和熔斷器Sentinel， 這些組件能同時兼容spring cloud和dubbo， 為spring cloud和dubbo的融合和同時使用提供了便利性， 而且比以前的組件更強大和更容易使用了。

1. 體系架構

         總結以上的分析，以下是朗尊軟件的架構師何文強所帶來的技術分享。以LegendShop電商系統為例， 先看一下整體的解決方案：

結合圖中所示，下面是這套電商系統所采用的技術的主要的技術棧。

1. 通過 API 的設計解耦，把整個系統根據業務拆分成若干個子系統或微服務

               客戶端通過API gateway來訪問內部的應用， 通過gateway來實現黑白名單，路由控制，權限控制等。一個后臺可以同時支持多個客戶端。

    2. 每個子系統可以部署多個應用，多個應用之間使用負載均衡

              每個服務會占用一個端口，同一個服務可以啟動多個實例。

    3.  服務注冊中心和配置中心都采用Nacos，所有的服務都在注冊中心注冊，負載均衡也是通過在注冊中心注冊的服務來使用一定策略來實現，以下是Nacos的截圖。

    4.   使用 OAuth3 認證完善外部交互的安全機制

     客戶端在調用gateway或者內部API的時候需要系統授權才行，要不就無法保證系統安全。本方案采用Oauth3進行權限驗證， 每個調用方都會分配一個appId和secretKey, 用戶調用API之前需要用appId和secretKey來換取合法的token，然后通過token來訪問系統的功能。OAuth3 是為用戶資源的授權提供的一個安全、開放、簡易的標準協議。OAuth3 的授權不會使第三方觸及到用戶的帳號信息，非常安全。而且任何第三方都可以使用 OAuth3 認證服務，在這套架構里，每一次來自外部的對微服務的請求，都要通過 OAuth3 服務器驗證。OAuth3 在此統一了眾多微服務的安全機制，并且將安全做到了微服務級別而不是網關級別。

   2. 敏捷開發

        關于敏捷開發，不得不提的是DevOps（Development和Operations的組合詞）。從百度得來的定義，DevOps是一組過程、方法與系統的統稱，用于促進開發（應用程序/軟件工程）、技術運營和質量保障（QA）部門之間的溝通、協作與整合。它是一種重視“軟件開發人員（Dev）”和“IT運維技術人員（Ops）”之間溝通合作的文化、運動或慣例。透過自動化“軟件交付”和“架構變更”的流程，來使得構建、測試、發布軟件能夠更加地快捷、頻繁和可靠。它的出現是由于軟件行業日益清晰地認識到：為了按時交付軟件產品和服務，開發和運維工作必須緊密合作。

  2.1 版本控制

       開發這塊目前是使用git來做版本控制，git的基本用法遵循以下的原則進行裁剪。

Master和develop分支是長期存在的分支，如果有bug出現的話就從打bug分支修改完再合并到develop分支。再由develop分支合并到master分支上，最后出版本從master版本上獲取代碼即可。

2.2 持續集成

     另外一個持續集成的工具優先采用Jenkins，其截圖如下：

Jenkins是一個功能強大的應用程序，允許持續集成和持續交付項目，無論用的是什么平臺。這是一個免費的源代碼，可以處理任何類型的構建或持續集成。集成Jenkins可以用于一些測試和部署技術。Jenkins是一種軟件允許持續集成。

Jenkins跟git/svn等這些代碼管理工具緊密工作，方便整個開發和部署。

2.3 Docker部署

由于微服務會分成比較多的獨立運行的系統， 如果都是手工部署的話，會比較繁瑣。因此不利于系統的長期穩定發展，采用Docker安裝的話，會化簡整個部署的步驟，并且提高了系統的安全性。系統部署的結構如下：

      每個微服務都是獨立運行的一個子系統。

    從百度得知，Docker 是一個開源的應用容器引擎，讓開發者可以打包他們的應用以及依賴包到一個可移植的鏡像中，然后發布到任何流行的 Linux或Windows 機器上，也可以實現虛擬化。容器是完全使用沙箱機制，相互之間不會有任何接口。 實踐中會發現，生產環境中使用單個 Docker 節點是遠遠不夠的，搭建 Docker 集群勢在必行。然而，面對 Kubernetes, Mesos 以及 Swarm 等眾多容器集群系統，我們該如何選擇呢？它們之中，Swarm 是 Docker 原生的，同時也是最簡單，最易學，最節省資源的，因此把Swarm作為系統的集群部署的解決方案。

Docker容器應用的開發和運行離不開可靠的鏡像管理，雖然Docker官方也提供了公共的鏡像倉庫，但是從安全和效率等方面考慮，部署我們私有環境內的Registry也是非常必要的。Harbor是由VMware公司開源的企業級的Docker Registry管理項目，它包括權限管理(RBAC)、LDAP、日志審核、管理界面、自我注冊、鏡像復制和中文支持等功能。

       采用Docker部署各種常規應用非常簡單， 只要一條命令或者一個yml文件即可。由于本文不是重點講解如何使用Docker，因此一筆帶過，請參考筆者其他的關于如何安裝Docker，Docker-compose、 Docker-swarm的文章。

1. 總結

        系統的升級和優化永無止境，只能根據實際情況不斷的調整和優化。微服務帶來的好處是能將系統細分為不同的子模塊， 適合中大型的系統開發。因為電商系統是跟客戶打交道的銷售型系統，這個行業性質跟企業內部使用的系統不一樣，決定了電商系統要做強做大的話，客戶量會有數個數量級的差別。而且客戶會提出各種各樣的需求，功能和界面也要跟著節日或者潮流來變化。所以這個微服務版本是針對多金客戶來使用比較合適，服務器和人力的消耗都比較多。 有些客戶一上來就說我要做一個淘寶，做一個京東，我要分表分庫。拜托，還是理智一點好。 不過微服務版本的電商系統也給了客戶一個能做夢的基礎。

        將來的10年是傳統線下行業向線上滲透的年代。對一般的中小型客戶使用集群版本就可以了。再小一點我只要做生意賣貨而已， 沒有什么特殊的需求，那就采用SAAS版本就好了。SAAS + PASS才是將來發展的道路， 畢竟專人做專事。

關于大型電商系統架構的微服務與敏捷開發實踐方法教程問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。