微服務技術選型

轉: http://www.youmeek.com/microservice/
後端類開發總結 / 預測

• 2018 ~ 2020 Spring Cloud Finchley 以及後續版本、Kubernetes 開始全面發力
• 2020 開始 ServiceMesh 開始發力
• 2020 ~ 2023 ServiceMesh 全面發力，Serverless 開始發力
• 2025 Serverless 全面佔據中小企業。

在商言商

• 一家公司在發現新的市場需求的時候，先發制人所產生的優點是很是重要的。因此美國利寶相互保險公司執行副總裁兼首席信息官 James McGlennon 說過這樣的話：

「咱們瞭解到的其中一件事是：若是你不能提升上市速度，毫無疑問，市場將發生變化，不管你對產品的設計、構建、部署或對員工的培訓有多好，都不會徹底適合市場需求，只由於晚了一點點。」 來源

• 能減小生產的投入，天然推廣的資源也就變多了，在保證良好服務的狀況下，市場佔有率就會越高。中小公司剛起步的時，系統壓力小，採購服務器資源少。隨着公司發展，部分功能模塊流量愈來愈大，而部分功能流量依舊稀少，有的功能是 CPU 型應用，有的是內存型應用，有的是存儲、寬帶等，若是公司能只針對壓力大的功能進行服務資源擴展那就行了。
• 由於這個需求，咱們也發現 IT 世界這幾年發生新的變化：
  • 雲服務
  • 容器
  • 微服務、先後端分離
  • DevOps
  • 服務網格（ServiceMesh）
  • 無服務器架構（Serverless）
• 咱們今天主要聊的是：微服務。至於其餘概念在後續文章會進行補充。

微服務的根：敏捷開發

瀑布式開發

• 在講敏捷開發以前須要說下它的對立面：不敏捷，也就是敏捷以前你們經常使用的開發模式：瀑布式開發。
• 瀑布式開發是一套經典的軟件工程方法論，其定義了一套完備的過程規範，使得軟件開發的運做就像是機器設備同樣正常的運轉而總結出來的項目管理方法論。
• 這套方法論分爲5個階段：需求分析、設計、編碼、測試和維護。
  • 需求分析階段一般定義系統的需求，明確系統的目標；
  • 設計階段一般肯定系統使用什麼數據庫，系統模塊的劃分，各個模塊的功能；
  • 編碼階段用編程語言實現設計階段的任務；測試階段主要測試功能是否實現，以及是否正確沒用Bug；
  • 維護階段是根據用戶新的需求從新修改系統，使系統運行正常，更加穩定。
• 現現在瀑布式開發通常在傳統行業使用，互聯網的公司現在通常用的是敏捷開發，那它爲何會互聯網公司這麼流行？主要仍是傳統軟件開發模式過程太繁瑣，且還有嚴格的文檔的要求，瞭解過日本外包可能能夠理解這個文檔的概念，因此對於互聯網行業這種傳統模式開發效率過低低。

敏捷開發

• 今天的主角是：微服務（Microservice Architecture，簡稱 MSA），這個概念其實很早就有了，只是沒人像 Martin Fowler 那樣進行系統整理、概括。
• 說到 Martin Fowler 那就得說道敏捷。Martin Fowler，這個老頭子在面向對象分析設計、UML、模式、軟件開發方法學、XP（敏捷極限編程）、重構等方面，都是世界頂級的專家，抽象能力不是通常的好。
• 由於 Martin 是敏捷先驅，早期敏捷宣言的起草人之一，因此在他所理解的開發世界中，敏捷開發是最爲關鍵的一個點。而敏捷開發有四個核心價值觀被咱們熟知：
  • 咱們一直在實踐中探尋更好的軟件開發方法，身體力行的同時也幫助他人。由此咱們創建了以下價值觀：
  • 個體和互動 高於 流程和工具（個人理解：以人爲本，有效溝通）
  • 工做的軟件 高於 詳盡的文檔（個人理解：以實際產出的有效軟件爲目的，文檔爲輔助）
  • 客戶合做 高於 合同談判（個人理解：產出的軟件最終是要服務客戶）
  • 響應變化 高於 遵循計劃（個人理解：世界上惟一不變的就是變化，咱們常常在變化過程當中發現咱們真正須要的）
  • 也就是說，儘管右項有其價值，咱們更重視左項的價值。
• 敏捷宣言還有一套原則，來輔助這四個核心價值：

咱們遵循如下原則： 咱們最重要的目標，是經過持續不斷地 及早交付有價值的軟件使客戶滿意。  欣然面對需求變化，即便在開發後期也同樣。 爲了客戶的競爭優點，敏捷過程掌控變化。  常常地交付可工做的軟件， 相隔幾星期或一兩個月，傾向於採起較短的週期。  業務人員和開發人員必須相互合做， 項目中的每一天都不例外。  激發個體的鬥志，以他們爲核心搭建項目。 提供所需的環境和支援，輔以信任，從而達成目標。  不論團隊內外，傳遞信息效果最好效率也最高的方式是 面對面的交談。  可工做的軟件是進度的首要度量標準。  敏捷過程倡導可持續開發。 責任人、開發人員和用戶要可以共同維持其步調穩定延續。  堅持不懈地追求技術卓越和良好設計，敏捷能力由此加強。  以簡潔爲本，它是極力減小沒必要要工做量的藝術。  最好的架構、需求和設計出自自組織團隊。  團隊按期地反思如何能提升成效， 並依此調整自身的舉止表現。

• 在 2001 年 2 月 Martin Fowler，Jim Highsmith 等 17 位著名的軟件開發專家忍不了這些低效率，總結了他們過去的經驗，提出了這個概念並發表宣言。
• 敏捷開發的特色就是：擁抱市場變化，積極響應市場需求，利用變化爲產品創造競爭優點。
• 可是也由於這樣的特色，敏捷開發在實際落地的時候不少團隊又遇到了新的問題：走兩個極端。
  • 一種極端：猶如敏捷宣言所說的：個體和互動高於流程和工具，工做的軟件高於詳盡的文檔。有些團隊理解成了，那就不須要詳細的計劃，不須要周全的架構。（好比咱們有些人就不喜歡寫 README.md）
  • 一種極端：既然需求都是在變的，那咱們就不斷根據變更需求開發、測試、測試、開發。（好比，咱們有的開發歷來不會思考需求是否真的符合人類的思惟。咱們開發者也是軟件的使用者。）
• 很明顯這種極端可能在咱們身邊都有出現過，咱們也感覺到這兩種極端所帶來的危害。
• 因此，在使用微服務的技術作項目以前，咱們須要先搞懂敏捷開發在整個項目開發過程當中關鍵點，這也是爲何介紹微服務開發以前以爲先應該說的。

模塊拆分（組件化）、服務拆分、分佈式、集羣、負載均衡、微服務、DevOps、先後端分離

模塊拆分

• 只是爲了讓代碼更加簡潔和能夠維護，根據技術帶來拆分模塊，模塊之間互相依賴。

服務拆分

• 是微服務的第一步，也是我認爲最重要的一步，也是最初最難的一步，拆的很差後面的設計也會有問題。
• 只有真正理解業務，摸清楚需求的核心，才能拆分出一個有良好邊界的模型。而且還要儘量考慮後續需求的變動。（固然，隨着時間的發展，咱們我的開發者閱歷的發展，終歸會有技術債務，可是隻能努力去克服）。
• 關於領域驅動設計（DDD）Martin Fowler 也在本身的博客也有文章。DDD 是著名建模專家 Eric Evans[‘erɪk ‘evənz] 提出來的，這兩我的都是抽象的大神，同一個界面的。
• 服務拆分，優先先找到核心領域，好比廣告系統：
  – 核心領域：商戶、渠道、推廣用戶、SKU、推廣任務、廣告、廣告成效
  – 通用領域：系統用戶、權限
  – 支撐領域：搜索、日誌、圖片、文件

分佈式

• 相對於單體系統，分佈式是指將一個業務拆分不一樣的子業務，分佈在不一樣的服務器上執行，不一樣服務器之間能夠互相通訊和協調。

• 圖片來源：小白科普：分佈式和集羣

集羣

• 是指多臺服務器集中在一塊兒，實現同一業務（同一個業務代碼部署多套到不一樣機子上），集合起來提供服務的（通常會配上負載均衡）。理論上，分佈式的系統通常都是帶集羣的。

• 圖片來源：小白科普：分佈式和集羣

負載均衡

• 高效分發請求

• 圖片來源：小白科普：分佈式和集羣

微服務

• 做者有關 Microservice 的原文：https://martinfowler.com/articles/microservices.html
• 中文翻譯：http://insights.thoughtworks.cn/microservices-2/
• 它不是框架，也不是系統，只是一種架構風格。因此咱們用的 dubbo [‘dʌbəu]、Spring Cloud 等框架，都是分佈式服務框架。只是這種分佈式服務框架都是微服務架構必不可少的基礎能力，微服務必定是分佈式的。分佈式服務的概念比較模糊，只是解決了網站的高併發問題，不少細節問題是微服務幫其明確的。微服務更增強調敏捷和健壯，強調服務的粒度，一個服務只需完成一個單一的、獨立的功能，多個微服務組合完成相對複雜的業務系統，以知足需求。並且微服務注重藉助於各類中間件進行業務解耦和提升性能，以及提升服務的容錯性。
• 因此，理論上：微服務的架構都是帶：模塊拆分、服務拆分、分佈式、集羣。
• 微服務其實在很早之前就有人/公司在作，只是過去沒人去給它作總結和思考它自己，而後 Martin Fowler 就幫咱們幫咱們作了。
• 單體系統在早期也沒啥很差，可是隨着 AWS 這種可彈性擴展的雲誕生以後，這種單體架構就顯得不夠時尚了，只有微服務的架構才能合理榨乾這些各類類型的雲服務。
  微服務的目的是有效的拆分應用，實現敏捷開發和部署 。

DevOps

• 咱們知道微服務的服務通常要單1、獨立，從技術上說，這是經過工具把應用程序的內部複雜度轉化爲外部複雜度，須要一系列工具支撐微服務自己以及服務之間的通訊。從組織上說，微服務團隊要知足「快速發佈，獨立部署」的能力，則必須具有 DevOps 的工做方式。

• 當咱們把服務拆分以後，團隊組織結構仍是保留單體系統的結構的時候會常常看到這類對話：

這個包在我本地運行沒有問題，部署到服務器出問題了，那確定是你那邊環境有問題呀（開發者說）

大家究竟是怎麼開發的，一部署上去，CPU 和 內存的佔用立馬暴增（運維人員說）

• 那簡單地講什麼是 DevOps（Deveplopment 和 Operations 的簡稱）？DevOps 是一種研發模式，方法論，2009 年開始發展起來，它不是框架或是技術的東西，是更好的優化開發(DEV)、測試(QA)、運維(OPS)的流程，開發運維一體化，經過高度自動化工具與流程來使得軟件構建、測試、發佈更加快捷、頻繁和可靠。主要目的在於提升用戶和業務需求提升產品的交付能力與效率。因此要踐行 DevOps 第一個要改變的就是管理理念。
• 在這些 DevOps 工具中，現現在有一個東西是必不可少的的：Docker（容器化）。到了今年 2018 年，若是是微服務系統，沒有用到容器化的技術的，通常也能夠認爲是微服務不夠的表現。
• 固然，更將來的技術也開始出現了：Serverless（無服務器風格的架構 AWS Lambda 免去了不少環境管理的工做，包括設備、網絡、主機以及對應的軟件和配置工做，使得軟件運行時環境更加穩定）
• DevOps 雖然不是技術，可是它有一堆的技術工具來踐行它的理念。
• 目前業界主流的 DevOps 工具箱有：
  • 版本控制&協做開發：GitHub、GitLab
  • 自動化構建和測試：Maven 、Gradle
  • 持續集成&交付：Jenkins、Travis CI
  • 容器平臺：Docker、Rocket、第三方廠商如（AWS/阿里雲）
  • 配置管理（或 Automated infrastructure ）：Chef、Puppet、Ansible
  • 微服務平臺：OpenShift、Cloud Foundry、Kubernetes、Mesosphere
  • 日誌管理：Logstash、CollectD、StatsD
  • 監控，警告&分析：Nagios、zabbix、ELK
  • 編輯器：IntelliJ IDEA
  • IM： Slack、釘釘
• 利用這些工具會產生什麼樣的效果：
  • 代碼的提交直接觸發測試、發佈
  • 各服務功能單一：使問題定位和調試變得簡單
  • 全開發流程高效自動化：穩定，快速，交付結果可預測
  • 持續進行自動化迴歸測試：提高交付質量
  • 設施共享並按需提供：資源利用最大化
• 由上能夠看出來：DevOps 和敏捷目的同樣，都是爲了更快、更好的交付。因此也有人認爲 DevOps 是敏捷的子集，也有一種說法是：新的敏捷概念：大規模敏捷（Scaling Agile），團結更多人的敏捷。
• 之前咱們認爲的敏捷基本都是認爲一個項目開發過程的敏捷，可是 DevOps 方法下，運維也是敏捷。
• 因此 Amazon CTO 2014 年有這樣一句話： 「You Build It, You Run It」（誰開發，誰運行）
• 目前的趨勢來看，隨着將來運維智能化，可能就是 NoOps 了。

先後端分離

• 這幾年前端發展太快，前端已經能夠很好滴作不少事情，因此術業有專攻，不少時候，若是項目大、公司開發人員足夠的話，最好都進行先後端分離。
• 分離以後咱們常會遇到下面幾個問題：
  • Mock。推薦用 YApi 工具，具體看 YApi 官網，本質仍是要了解 mockjs。
  • 開發階段的調試：Swagger
  • 跨域問題：後端 Spring MVC 須要配置 CORS 相關（CORS = Cross-Origin Resource Sharing，在服務器端設置響應頭，把發起跨域的原始域名添加到Access-Control-Allow-Origin 便可）。
  • 接口版本：在請求頭有版本標識，後臺接口 mapping 地址不變，擴展多個私有方法，根據請求版原本區分調用哪一個。
  • 數據傳輸格式統一：JSON（無論是接受仍是發送。除了批量初始化數據這類操做，建議 CSV 文件上傳，後端用流方式）
  • 認證。這裏主推 JWT，具體能夠看我這篇 優化單點登陸流程的好東西：JWT 介紹
  • 權限控制。若是有網關的話，後端的用戶的認證和鑑權都是在網關進行處理。前端在用戶登陸後拿到用戶權限列表標識，頁面根據這些標識判斷是否有對應的按鈕、菜單權限。
  • SEO 問題。內部系統不須要，面向廣大用戶的外部系統能夠 Google 下。
• 根據實踐，通常建議前端開發者給後端作一些目前大前端的基礎培訓，讓他們能夠簡單看懂代碼，會修改簡單組件便可。

微服務團隊

• 根據康威定律：設計一個系統的任何組織（廣義上）都會產生這樣一種設計，其結構是組織交流結構的複製。
• 意思就是：設計一個系統的團隊結構將決定了一個軟件系統的結構，將人員劃分爲 UI 團隊，中間件團隊，DBA 團隊，那麼相應地，軟件系統也就會天然地被劃分爲 UI 界面，中間件系統，數據庫。而一個高效的微服務團隊會針對這種狀況進行改善，微服務團隊須要是一個全棧的團隊，跨職能的團隊，應該包含整個項目週期的全部技能，先後端開發、UI設計、測試、構建部署、上線與運維都是必須技能。
• 這種組織結構的好處是：在業務服務的內部實現須要升級或者變動時，團隊內的各角色成員進行溝通便可，而不須要進行跨團隊溝通，這大大提升了溝通效率。只有服務之間的接口須要變動時才須要跨部門溝通，若是前期在服務之間的交互上定義了良好的接口，則接口變動的機率並不大，即便接口模式有變動，也能夠經過必定的設計模式和規範來解決。

引入微服務帶來的技術問題

• 既然微服務的目的是有效的拆分應用，實現敏捷開發和部署，那拆分後的新模式確定會帶來新的問題。
  • 客戶端怎麼訪問 N 個服務？
  • N 個服務怎麼管理？
  • N 個服務如何通訊？
  • 服務掛了怎麼處理？
  • 服務變成無狀態？
  • 網絡開銷？

微服務是如何解決

客戶端如何訪問這些服務？

• 引入 API Gateway（網關），提供統一服務入口，讓微服務對前臺透明，方便客戶端調用
• 引入網關最大的問題是：單點故障，性能瓶頸。

服務是如何通訊？

• 最通用的有兩種方式：
• 同步調用：
  • REST
  • RPC（Thrift, Dubbo）
• 異步調用：
  • MQ、Kafka
  • 異步主要是能夠下降調用服務之間的耦合，又能成爲調用之間的緩衝，確保消息積壓不會沖垮被調用方，同時能 保證調用方的服務體驗，繼續幹本身該乾的活，不至於被後臺性能拖慢。

這麼多服務，怎麼找?

• 在微服務架構中，通常每個服務都是有多個拷貝，來作負載均衡。一個服務隨時可能下線，也可能應對臨時訪問壓力增長新的服務節點。服務之間如何相互感知？服務如何管理？Dubbo 是用 zookeeper 來管理。

這麼多服務，服務掛了怎麼辦？

• 隨機中一個，多個服務器掛了是正常，可是服務仍是得照樣提供，因此咱們須要解決：
  • 重試機制
  • 限流
  • 熔斷機制
  • 負載均衡
  • 降級

難點

多套系統的數據

• 每一個微服務都有本身獨立的數據庫，那麼後臺管理的聯合查詢怎麼處理？這應該是你們會廣泛遇到的一個問題，目前常見有三種處理方案。
  • 嚴格按照微服務的劃分來作，微服務相互獨立，各微服務數據庫也獨立，後臺須要展現數據時，調用各微服務的接口來獲取對應的數據，再進行數據處理後展現出來，這是標準的用法，也是最麻煩的用法。
  • 將業務高度相關的表放到一個庫中，將業務關係不是很緊密的表嚴格按照微服務模式來拆分，這樣既可使用微服務，也避免了數據庫分散致使後臺系通通計功能難以實現，是一個折中的方案。
  • 數據庫嚴格按照微服務的要求來切分，以知足業務高併發，實時或者準實時將各微服務數據庫數據同步到 NoSQL 數據庫中，在同步的過程當中進行數據清洗，用來知足後臺業務系統的使用，推薦使用 MongoDB、Elasticsearch、HBase 等。
• 將來 TiDB 這類 NewSQL 成熟了，咱們就會好過點。

微服務架構的數據一致性問題

• 以電商平臺爲例，當用戶下單並支付後，系統須要修改訂單的狀態而且增長用戶積分。因爲系統採用的是微服務架構，分離出了支付服務、訂單服務和積分服務，每一個服務都有獨立數據庫作數據存儲。當用戶支付成功後，不管是修改訂單狀態失敗仍是增長積分失敗，都會形成數據的不一致。目前常見的三種方式解決最終一致性：
  • 可靠消息最終一致性
  • TCC（Try-Confirm-Cancel）
  • 最大努力通知
• 三者比較：

微服務的主要組件

• 常見的微服務組件及概念
  • 服務註冊，服務提供方將本身調用地址註冊到服務註冊中心，讓服務調用方可以方便地找到本身。
  • 服務發現，服務調用方從服務註冊中心找到本身須要調用的服務的地址。
  • 負載均衡，服務提供方通常以多實例的形式提供服務，負載均衡功能可以讓服務調用方鏈接到合適的服務節點。而且，節點選擇的工做對服務調用方來講是透明的。
  • 服務網關，服務網關是服務調用的惟一入口，能夠在這個組件是實現用戶鑑權、動態路由、灰度發佈、A/B測試、負載限流等功能。
  • 配置中心，將本地化的配置信息（properties, xml, yaml等）註冊到配置中心，實現程序包在開發、測試、生產環境的無差異性，方便程序包的遷移。
  • API管理，以方便的形式編寫及更新API文檔，並以方便的形式供調用者查看和測試。
  • 集成框架，微服務組件都以職責單一的程序包對外提供服務，集成框架以配置的形式將全部微服務組件（特別是管理端組件）集成到統一的界面框架下，讓用戶可以在統一的界面中使用系統。
  • 分佈式事務，對於重要的業務，須要經過分佈式事務技術（TCC、高可用消息服務、最大努力通知）保證數據的一致性。
  • 調用鏈，記錄完成一個業務邏輯時調用到的微服務，並將這種串行或並行的調用關係展現出來。在系統出錯時，能夠方便地找到出錯點。
  • 支撐平臺，系統微服務化後，系統變得更加碎片化，系統的部署、運維、監控等都比單體架構更加複雜，那麼，就須要將大部分的工做自動化。

Java 的微服務方案：Spring Boot、Spring Cloud

• 先推薦業界的 Spring Cloud 最佳實戰：https://github.com/sqshq/PiggyMetrics
• Spring Cloud 起源於 Netflix （網飛）的 NetflixOSS（由於是基於 Spring Boot，因此是和 Spring 深度合做的產物），而且在他們的產品上獲得成功驗證，也是目前業界最承認並推崇微服務框架。
• 關於 Spring Boot 和 Spring Cloud 二者之間的關係能夠這樣簡單粗暴地理解：
  • 由於：
    • Spring Core == Spring Boot
    • Spring MVC == Spring Cloud
  • 全部：
    • Spring MVC 依賴 Spring Core
    • Spring Cloud 依賴 Spring Boot
• 可是，Spring Boot 嚴格同樣上不算是一個框架（也算是框架），應該是說 Spring 框架的一個組合表達方式。這種表達方式主要是爲了解決過往 Spring 項目中各類 xml 文件配置、各類依賴包帶來複雜度。
• Spring Cloud 是微服務的各個服務的管家。這些集合主要解決：服務發現註冊、配置中心、網關路由、消息總線、負載均衡、斷路器、數據監控等，實現這些功能組件有：
  • Spring Cloud Config：配置管理工具包，讓你能夠把配置放到遠程服務器，集中化管理集羣配置，目前支持本地存儲、Git以及Subversion。
  • Spring Cloud Bus：事件、消息總線，用於在集羣（例如，配置變化事件）中傳播狀態變化，可與 Spring Cloud Config 聯合實現熱部署。
  • Eureka [jʊ’rikə]：雲端服務發現，一個基於 REST 的服務，用於定位服務，以實現雲端中間層服務發現和故障轉移。
  • Hystrix [hɪst’rɪks] ：熔斷器，容錯管理工具，旨在經過熔斷機制控制服務和第三方庫的節點,從而對延遲和故障提供更強大的容錯能力。
  • Ribbon [‘rɪbən]：提供雲端負載均衡，有多種負載均衡策略可供選擇，可配合服務發現和斷路器使用。
  • Feign [fen]：Feign是一種聲明式、模板化的HTTP客戶端。
  • Zuul：Zuul 是在雲平臺上提供動態路由,監控,彈性,安全等邊緣服務的框架。Zuul 至關因而設備和 Netflix 流應用的 Web 網站後端全部請求的前門。
  • Turbine [‘tɝbaɪn]：是聚合服務器發送事件流數據的一個工具，用來監控集羣下 hystrix 的 metrics 狀況。
  • Spring Cloud OAuth2 – 基於 Spring Security 和 OAuth2 的安全工具包，爲你的應用程序添加安全控制。
  • Spring Cloud Sleuth [sluθ]：日誌收集工具包，封裝了Dapper和log-based追蹤以及Zipkin和HTrace操做，爲SpringCloud應用實現了一種分佈式追蹤解決方案。
  • Spring Cloud Stream：基於Redis,Rabbit,Kafka實現的消息微服務，簡單聲明模型用以在Spring Cloud應用中收發消息。
• 實際常見的流程：
  • 請求統一經過API網關（Zuul）來訪問內部服務，在網關這一步作認證和鑑權
  • 認證和鑑權後，網關從註冊中心（Eureka）獲取可用服務
  • 由Ribbon進行均衡負載後，分發到後端具體實例
  • 微服務之間經過Feign進行通訊處理業務
  • Hystrix 負責處理服務超時熔斷
  • Turbine 監控服務間的調用和熔斷相關指標
  • Sleuth + Zipkin 將全部的請求數據記錄下來，方便咱們進行後續分析（分佈式鏈路跟蹤）

最終我的在技術選型上的選擇

• 優先級高
  • 統一環境：NTP、時區、hosts
  • 服務註冊：Eureka
  • 熔斷器：Hystrix + Turbine
  • 網關：zuul
  • 客戶端負載均衡：Ribbon
  • 內部服務調用：Feign
  • 認證鑑權：Spring Cloud OAuth2 + JWT
  • 分佈式調用鏈監控：Spring Cloud Sleuth + Zipkin
  • 狀態機：Spring StateMachine
  • 數據庫：MyCAT + MySQL 5.7
  • 部署：Docker
  • 持續集成：Jenkins
  • 構建工具：Maven
  • 版本控制：Gogs
  • 項目管理：TAPD
  • 後臺 API 文檔：Swagger
• 優先級中
  • 消息隊列：Kafka
  • 日誌收集：ELK + Kafka
  • 圖片系統：FastDFS
  • 分佈式調度：xxl-job
  • 緩存：Redis
  • API Mock：YApi
  • 前端：Angular
  • 程序監控：Spring Boot Admin / Spring Boot Actuator
• 優先級低
  • 分佈式配置中心：Spring Cloud Config Monitor / Apollo（攜程）
  • Docker 監控：CAdvisor + InfuxDB + Grafana

資料

• 敏捷軟件開發宣言
• 敏捷宣言遵循的原則
• 敏捷宣言以及敏捷開發的特色
• 敏捷開發的起源和發展歷史
• PM學項目管理之：什麼是敏捷開發？（上）
• 《微服務：從設計到部署》中文版
• 微服務（Microservice）那點事
• 從架構演進的角度聊聊Spring Cloud都作了些什麼？
• 微服務從設計到部署（一）微服務簡介
• 如何構建微服務架構
• 微服務架構的核心要點和實現原理
• 中小型研發團隊架構實踐：微服務架構
• 微服務架構技術棧選型手冊
• 部署微服務的時候，Spring Cloud 和 Kubernetes 哪一個更好？
• 關於Cloud Native架構與Matt Stine的一次對話
• 實現雲原生應用，先理解架構微服務化
• 零基礎玩轉Serverless
• 所謂Serverless，你理解對了嗎？
• Serverless 架構的優缺點
• DevOps詳解
• 大規模敏捷（Scaling Agile）方法分析
• 基於 Docker 實現 DevOps 的一些探索
• 給 DevOps 初學者的入門指南
• 服務拆分與架構演進

標籤： Java Web 開發