資訊專欄INFORMATION COLUMN
摘要：微服務簡介微服務架構是一種架構概念，旨在通過將功能分解到各個離散的服務中以實現對解決方案的解耦。每個微服務僅關注于完成一件任務并很好地完成該任務。服務異常自動隔離。微服務架構挑戰服務規模大，部署運維管理難度大。
微服務簡介
微服務架構（Microservice Architecture）是一種架構概念，旨在通過將功能分解到各個離散的服務中以實現對解決方案的解耦。
微服務是一種架構風格，一個大型復雜軟件應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注于完成一件任務并很好地完成該任務。在所有情況下，每個任務代表著一個小的業務能力。
應用架構發展 單體架構單體應用 就是將所有的業務場景的表示層、業務邏輯層和數據訪問層放在一個工程中。最終經過編譯、打包，部署在一臺服務器上。典型例子是j2ee的war包或ear包。
在應用的初始階段，單體架構無論是在開發速度、運維難度上，還是服務器的成本上都有著顯著的優勢。在一個產品的前景不明確的初始階段，用單體架構是非常明智的選擇。隨著應用業務的發展和業務復雜度的提高，這種架構明顯存在很多的不足，主要體現在以下3個方面。
缺點：
隨著業務擴張，開發難度加大，動一發而遷全身，代碼的可讀性、可維護性和可擴展性下降，業務擴展帶來的代價越來越大，開發都在同一個項目改代碼，相互等待，沖突不斷。
部署啟動時間較長，期間服務會中斷，模塊間相互影響較多，測試難難度加大，一個微小的問題，都可能導致整個應用掛掉。
性能容量有限，無法滿足高并發下的業務需求，受單機限制（縱向擴展），有性能瓶頸。
集群架構隨著業務的發展，大多數公司會將單體應用進行集群部署，并增加負載均衡服務器（例如Nginx、F5等），以應對用戶量的增加而帶來的高并發訪問量。此時的系統架構如圖1-3所示。
優化策略：
負載均衡，通過分發服務器，將用戶的訪問分派到不同的應用服務器，應用服務器的負載不再成為瓶頸，用戶量增加時，添加應用服務器即可。
添加緩存，使用緩存服務器來緩解數據庫的數據以及數據庫讀取數據的壓力。大多數的讀取操作是由緩存完成的，但是仍然有少數讀操作是從數據庫讀取。
讀寫分離，當有大量的讀寫操作時，將數據庫進行讀寫分離是一個不錯的選擇，例如MySQL的主從熱備份，通過相關配置可以將主數據庫服務器的數據同步到從數據庫服務器，實現數據庫的讀寫分離，讀寫分離能夠改善數據庫的負載能力。
分區分庫分表，將數據量較大的表水平或垂直切分，分散到不同的庫或主機上，分散數據庫的壓力，提高性能。
應用拆分，將較重要或訪問量較大的功能模塊拆分出來作為新應用多帶帶開發、運維。新應用與老應用間的相關依賴通過接口調用或其它方式交互。
集群有一定的處理高并發的能力，也能應對一定復雜的業務需求，改善了系統的性能，但是依然沒有改變系統為單體架構的事實，此時存在的不足之處如下。
缺點：
并發容量雖有提高，但有限。雖做一定的應用拆分后，一定程度上可以緩解單體應用的問題。但隨著服務拆分越來越多，開發、部署、運維、管理難度也越來越大。
持續交付能力差，業務越復雜，代碼越多，修改代碼和添加代碼所需的時間越長。新人熟悉代碼的時間長、成本高。
子應用間依賴耦合較緊，重復功能建設，重復代碼等，服務間通信沒有標準等。
微服務架構“微服務”最初是由Martin Fowler 在2014年寫的一篇文章《MicroServices》中提出來的。關于Martin Fowler的介紹
Martin Fowler是國際著名的OO專家，敏捷開發方法的創始人之一，現為ThoughtWorks公司的首
席科學家。在面向對象分析設計、UML、模式、軟件開發方法學、XP、重構等方面，都是世界頂級的
專家，現為Thought Works公司的首席科學家。Thought Works是一家從事企業應用開發和——集
成的公司。早在20世紀80年代，Fowler就是使用對象技術構建多層企業應用的倡導者，他著有幾
本經典書籍： 《企業應用架構模式》、《UML精粹》和《重構》等。
相對于大規模的集群，微服務帶來了質的飛越，不僅僅是服務拆分，微服務是一整套的服務治理的架構，具備整套的設施。
微服務架構領域特性：
每個服務為獨立的業務開發，多帶帶部署，跑在自己的進程中。
自動化測試、部署、運維（ DevOps ）。
快速演化、快速迭代。
整個業務由一系列的獨立的服務共同組成系統。
高度容錯性、高可用、高并發。
具備能力：
注冊中心：應用啟動自動注冊，調用方自動發現上線應用。服務異常自動隔離。
配置中心：多環境配置管理，支持在線管理配置信息，客戶端實時生效。支持版本管理，快速回滾。
消息中心：服務間異步通信的總線。
負載均衡：服務調用服務會采用一定的分發策略，一般是客戶端分發策略。
服務間通信：使用http或RPC協議進行服務調用，REST、gRPC、Thrift、hession等
服務降級、熔斷、重試：降級，服務或依賴服務異常時，返回保底數據。熔斷，若依賴服務多次失效，則斷開，不再嘗試調用，直接返回降級值。重試，熔斷后，定期探測依賴服務可用性，若恢復則恢復調用。
服務發布與回滾：紅綠部署、灰度、AB Test等發布策略，可快速回滾應用。
服務動態伸縮、容器化：根據服務負載情況，可快速手動或自動進行節點增加和減少。
服務監控與告警：服務定期健康檢察、指標統計、異常告警通知運維。
請求緩存與合并：服務間調用相同請求緩存，類似請求合并成批量請求，減少服務間通信，提高性能。
服務網關：用戶請求過載時進行限流、排隊，過載保護，黑白名單、異常用戶過濾攔截等。
服務依賴、文檔、Mock Server、版本管理：自動生成接口文檔，接口版本化管理，Mock接口等。
日志收集、追蹤、分析：集中收集各服務日志匯總，方便排障、問題調查、應用日志分析等。
性能監測APM：對各服務性能進行監測與分析，為服務優化提供數據支持。
以上我整理的微服務相關應具備的能力，內容相當的多，要搭建這樣一套完善的微服務平臺，花費的財力和時間都是巨大的。幸好開源界已經在各方面有眾多的可選方案。
微服務架構挑戰服務規模大，部署、運維、管理難度大。
服務間調用關系復雜，調用鏈路長，排障難度大。
服務間通信成本變大，性能和容錯帶來的挑戰。
服務間依賴較多，系統集成、測試難度變大。
開發人員技術能力挑戰，各服務間重復代碼，重復建設等。
集群規模大，功能性能監控、告警帶來的挑戰。
大規模分布式，數據一致性帶來的挑戰。
需求和版本協調復雜度大大增加，測試難度也增加。
對基礎架構要求大大提高，規模大幅增加。
微服務實施 SpringCloudSpringCloud是在SpringBoot基礎之上構建的快速開發分布式系統（微服務）的工具集。
為開發人員提供了一個開箱即用，快速構建微服務的一些通用組件（例如配置管理，服務發現，斷路器，智能路由，消息總線等）。
官網
DubboDubbo是阿里巴巴公司開源的一個高性能優秀的服務框架，使得應用可通過高性能的RPC實現服務的輸出和輸入功能，可以和Spring框架無縫集成。
官網
下一代微服務Service Mesh(網格服務)Service Mesh 架構圖：
Service Mesh 開源項目簡介：
Linkerd（https://github.com/linkerd/li...）：
第一代 Service Mesh，2016 年 1 月 15 日首發布，業界第一個 Service Mesh 項目，由 Buoyant 創業小公司開發（前 Twitter 工程師），2017 年 7 月 11 日，宣布和 Istio 集成，成為 Istio 的數據面板。
Envoy（https://github.com/envoyproxy...）：
第一代 Service Mesh，2016 年 9 月 13 日首發布，由 Matt Klein 個人開發（Lyft 工程師），之后默默發展，版本較穩定。
Istio（https://github.com/istio/istio）：
第二代 Service Mesh，2017 年 5 月 24 日首發布，由 Google、IBM 和 Lyft 聯合開發，只支持 Kubernetes 平臺，2017 年 11 月 30 日發布 0.3 版本，開始支持非 Kubernetes 平臺，之后穩定的開發和發布。
Conduit（https://github.com/runconduit...）：
第二代 Service Mesh，2017 年 12 月 5 日首發布，由 Buoyant 公司開發（借鑒 Istio 整體架構，部分進行了優化），對抗 Istio 壓力山大，也期待 Buoyant 公司的毅力。
nginMesh（https://github.com/nginmesh/n...）：
2017 年 9 月首發布，由 Nginx 開發，定位是作為 Istio 的服務代理，也就是替代 Envoy，思路跟 Linkerd 之前和 Istio 集成很相似，極度低調，GitHub 上的 star 也只有不到 100。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/11895.html
摘要：邊緣計算框架簡介服務層是一系列松耦合開源的微服務集合。處理北向應用發往南向設備的請求當然該服務還會處理框架內其他微服務發往南向設備的請求，如本地的分析服務。 EdgeX Foundry邊緣計算框架簡介 EdgeX Foundry服務層 EdgeX Foundry是一系列松耦合、開源的微服務集合。該微服務集合構成了四個微服務層及兩個增強的基礎系統服務，這四個微服務層包含了從物理域數據采集...
摘要：邊緣計算框架簡介服務層是一系列松耦合開源的微服務集合。處理北向應用發往南向設備的請求當然該服務還會處理框架內其他微服務發往南向設備的請求，如本地的分析服務。 EdgeX Foundry邊緣計算框架簡介 EdgeX Foundry服務層 EdgeX Foundry是一系列松耦合、開源的微服務集合。該微服務集合構成了四個微服務層及兩個增強的基礎系統服務，這四個微服務層包含了從物理域數據采集...
摘要：本文簡單介紹是什么，為什么用，怎么用。技術棧是什么是一個開發平臺，用于生成，開發，部署和。實現需定制化源碼。 本文簡單介紹Jhipster是什么，為什么用Jhipster，怎么用Jhipster。 WHAT - 技術棧 JHipster是什么 JHipster是一個開發平臺，用于生成，開發，部署Spring Boot + Angular/React Web Application和Sp...
摘要：在將臭未臭之前，我們趕緊把其中的統一認證這塊過一下。的歷史前面說了是耶魯大學實驗室的在年出的一個開源系統。這次我們先看看官網出的一幅圖，這張圖片介紹了的組成以及支持的各種協議，各種特性，不煩看看 為什么要做這個嘗試？ 微服之道，方興未艾；農之來學者，蓋已千者！ 這句是從《陶山集·太學案問》瞎改出來的。意思就是微服務的架構理念還在不斷地發展，現在整個啥都 言必出微服務，差點都到了 沒學...
摘要：作為微服務的基礎設施之一，背靠強大的生態社區，支撐技術體系。微服務實踐為系列講座，專題直播節，時長高達小時，包括目前最流行技術，深入源碼分析，授人以漁的方式，幫助初學者深入淺出地掌握，為高階從業人員拋磚引玉。 簡介 目前業界最流行的微服務架構正在或者已被各種規模的互聯網公司廣泛接受和認可，業已成為互聯網開發人員必備技術。無論是互聯網、云計算還是大數據，Java平臺已成為全棧的生態體系，...
閱讀 1329·2021-09-04 16:40
閱讀 3455·2021-07-28 00:13
閱讀 2878·2019-08-30 11:19
閱讀 2611·2019-08-29 12:29
閱讀 3167·2019-08-29 12:24
閱讀 1122·2019-08-26 13:28
閱讀 2386·2019-08-26 12:01
閱讀 3445·2019-08-26 11:35
