<del id="nnjnj"></del><track id="nnjnj"></track>

<p id="nnjnj"></p>

<address id="nnjnj"></address>

    <pre id="nnjnj"><pre id="nnjnj"></pre></pre>

      <noframes id="nnjnj"><ruby id="nnjnj"><ruby id="nnjnj"></ruby></ruby>

      • 自動秒收錄
      • 軟件:1973
      • 資訊:57811|
      • 收錄網站:279872|

      IT精英團

      【12張手繪】我懂微服務架構!

      【12張手繪】我懂微服務架構!

      瀏覽次數:
      評論次數:
      編輯: 溫瑜
      信息來源: ITPUB
      更新日期: 2022-08-18 21:55:47
      摘要

      .css-1yuhvjn{margin-top:16px;}.css-3jt6os.FileLinkCard{-webkit-align-items:center;-webkit-box-align

      • 正文開始
      • 相關閱讀
      • 推薦作品
      inkCard-title.two-line{line-height:20px;display:-webkit-box;text-overflow:ellipsis;overflow:hidden;-webkit-box-orient:vertical;-webkit-line-clamp:2;}.css-1wr1m8 .LinkCard.new .LinkCard-title.loading{margin-bottom:8px;width:80%;}.css-1wr1m8 .LinkCard.new .LinkCard-title.loading.withTitle{margin-bottom:6px;}.css-1wr1m8 .LinkCard.new .LinkCard-title.loadingTitle{margin-bottom:5px;}.css-1wr1m8 .LinkCard.new .LinkCard-excerpt{display:-webkit-box;text-overflow:ellipsis;font-size:13px;line-height:18px;color:#999999;margin-bottom:4px;overflow:hidden;-webkit-box-orient:vertical;-webkit-line-clamp:1;}.css-1wr1m8 .LinkCard.new .LinkCard-excerpt .LinkCard-author{color:#444444;}.css-1wr1m8 .LinkCard.new .LinkCard-desc{display:-webkit-box;font-size:13px;height:18px;line-height:18px;color:#999999;word-break:break-all;text-overflow:ellipsis;overflow:hidden;-webkit-box-orient:vertical;-webkit-line-clamp:1;}.css-1wr1m8 .LinkCard.new .LinkCard-desc .LinkCard-tag,.css-1wr1m8 .LinkCard.new .LinkCard-desc .tag{display:inline-block;font-size:11px;margin-left:8px;padding:0 4px;border-radius:3px;background:rgba(211,211,211,0.3);}.css-1wr1m8 .LinkCard.new .LinkCard-desc.loading{width:40%;}.css-1wr1m8 .LinkCard.new .LinkCard-desc svg{margin-right:2px;}.css-1wr1m8 .LinkCard.new .LinkCard-image{-webkit-flex:0 0 auto;-ms-flex:0 0 auto;flex:0 0 auto;background-color:#EBEBEB;background-size:cover;background-position:center;position:relative;display:block;width:60px;height:60px;margin-left:20px;object-fit:cover;border-radius:inherit;overflow:hidden;}.css-1wr1m8 .LinkCard.new .LinkCard-image.LinkCard-image--default{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;-webkit-box-pack:center;-webkit-justify-content:center;-ms-flex-pack:center;justify-content:center;background-color:#EBEBEB;color:#D3D3D3;}.css-1wr1m8 .LinkCard.new .LinkCard-image.LinkCard-image--default svg{color:#999999;}.css-1wr1m8 .LinkCard.new .LinkCard-image img{width:100%;height:100%;object-fit:cover;}.css-1wr1m8 .LinkCard.new .LinkCard-image .LinkCard-image--video{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;-webkit-box-pack:center;-webkit-justify-content:center;-ms-flex-pack:center;justify-content:center;position:absolute;top:50%;left:50%;-webkit-transform:translateX(-50%) translateY(-50%);-ms-transform:translateX(-50%) translateY(-50%);transform:translateX(-50%) translateY(-50%);width:24px;height:24px;border-radius:12px;background:rgba(255,255,255,0.9);pointer-events:none;}.css-1wr1m8 .LinkCard.new .LinkCard-image .LinkCard-image--video svg{color:#444444;}.css-1wr1m8 .LinkCard.new .LinkCard-richText .text{color:#444444;}.css-1wr1m8 .LinkCard.new .LinkCard-richText .bold{font-weight:600;}.css-1wr1m8 .LinkCard.new .LinkCard-richText .tag{margin-left:4px;}.css-1wr1m8 .LinkCard.old{position:relative;display:block;margin:1em auto;width:390px;box-sizing:border-box;border-radius:12px;max-width:100%;overflow:hidden;}.css-1wr1m8 .LinkCard.old,.css-1wr1m8 .LinkCard.old:hover{-webkit-text-decoration:none;text-decoration:none;border:none !important;color:inherit !important;}.css-1wr1m8 .LinkCard-ecommerceLoadingCard{position:relative;display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;-webkit-box-pack:justify;-webkit-justify-content:space-between;-ms-flex-pack:justify;justify-content:space-between;padding:12px;border-radius:inherit;height:80px;box-sizing:border-box;background:rgba(246,246,246,0.88);color:#D3D3D3;}.css-1wr1m8 .LinkCard-ecommerceLoadingCardAvatarWrapper{width:60px;height:60px;background:#EBEBEB;display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;-webkit-box-pack:center;-webkit-justify-content:center;-ms-flex-pack:center;justify-content:center;border-radius:6px;margin-right:10px;}.css-1wr1m8 .LinkCard-ecommerceLoadingCardNetwork{width:20px;height:20px;}.css-1wr1m8 .LinkCard-ecommerceLoadingCardLoadingbar{height:60px;-webkit-flex:1;-ms-flex:1;flex:1;display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-flex-direction:column;-ms-flex-direction:column;flex-direction:column;}.css-1wr1m8 .LinkCard-ecommerceLoadingCardLoadingbar span{height:16px;display:inline-block;background:#EBEBEB;}.css-1wr1m8 .LinkCard-ecommerceLoadingCardLoadingbar span:nth-of-type(1){width:60px;margin-bottom:4px;}.css-1wr1m8 .LinkCard-ecommerceLoadingCardLoadingbar span:nth-of-type(2){width:127px;}

      微服務的概念最早在 2012 年提出,在 Martin Fowler 的大力推廣下,微服務在 2014 年后得到了大力發展。今天我們通過一組手繪圖來梳理下微服務的核心架構。

      什么是微服務?

      微服務 Microservices 之父,馬丁.福勒,對微服務大概的概述如下:

      就目前而言,對于微服務業界并沒有一個統一的、標準的定義(While there is no precise definition of this architectural style ) 。
      但通常在其而言,微服務架構是一種架構模式或者說是一種架構風格,它提倡將單一應用程序劃分成一組小的服務,每個服務運行獨立的自己的進程中,服務之間互相協調、互相配合,為用戶提供最終價值。
      服務之間采用輕量級的通信機制互相溝通(通常是基于 HTTP 的 RESTful API ) 。每個服務都圍繞著具體業務進行構建,并且能夠被獨立地部署到生產環境、類生產環境等。
      另外,應盡量避免統一的、集中式的服務管理機制,對具體的一個服務而言,應根據業務上下文,選擇合適的語言、工具對其進行構建,可以有一個非常輕量級的集中式管理來協調這些服務??梢允褂貌煌恼Z言來編寫服務,也可以使用不同的數據存儲。

      根據馬丁.福勒的描述,我總結了以下幾點:

      ①小服務

      小服務,沒有特定的標準或者規范,但他在總體規范上一定是小的。

      ②進程獨立

      每一組服務都是獨立運行的,可能我這個服務運行在 Tomcat 容器,而另一個服務運行在 Jetty 上??梢酝ㄟ^進程方式,不斷的橫向擴展整個服務。

      ③通信

      過去的協議都是很重的,就像 ESB,就像 SOAP,輕通信,這意味著相比過去更智能更輕量的服務相互調用,就所謂 smart endpoints and dumb pipes。

      這些 Endpoint 都是解耦的,完成一個業務通信調用串起這些 Micro Service 就像是 Linux 系統中通過管道串起一系列命令業務。

      過去的業務,我們通常會考慮各種各樣的依賴關系,考慮系統耦合帶來的問題。微服務,可以讓開發者更專注于業務的邏輯開發。

      ④部署

      不止業務要獨立,部署也要獨立。不過這也意味著,傳統的開發流程會出現一定程度的改變,開發的適合也要有一定的運維職責。

      ⑤管理

      傳統的企業級 SOA 服務往往很大,不易于管理,耦合性高,團隊開發成本比較大。

      微服務,可以讓團隊各思其政的選擇技術實現,不同的 Service 可以根據各自的需要選擇不同的技術棧來實現其業務邏輯。

      微服務的利與弊

      為什么用微服務呢?因為好玩?不是的。下面是我從網絡上找到說的比較全的優點:

      • 優點是每個服務足夠內聚,足夠小,代碼容易理解這樣能聚焦一個指定的業務功能或業務需求。
      • 開發簡單、開發效率提高,一個服務可能就是專一的只干一件事。
      • 微服務能夠被小團隊單獨開發,這個小團隊是 2 到 5 人的開發人員組成。
      • 微服務是松耦合的,是有功能意義的服務,無論是在開發階段或部署階段都是獨立的。
      • 微服務能使用不同的語言開發。
      • 易于和第三方集成,微服務允許容易且靈活的方式集成自動部署,通過持續集成工具,如 Jenkins,Hudson,bamboo。
      • 微服務易于被一個開發人員理解,修改和維護,這樣小團隊能夠更關注自己的工作成果。無需通過合作才能體現價值。微服務允許你利用融合最新技術。
      • 微服務只是業務邏輯的代碼,不會和 HTML,CSS 或其他界面組件混合。
      • 每個微服務都有自己的存儲能力,可以有自己的數據庫,也可以有統一數據庫。

      總的來說,微服務的優勢,就是在于,面對大的系統,可以有效的減少復雜程度,使服務架構的邏輯更清晰明了。

      但是這樣也會帶來很多問題,就譬如分布式環境下的數據一致性,測試的復雜性,運維的復雜性。

      什么組織適合使用微服務?

      微服務帶了種種優點,種種弊端,那么什么組織適合使用微服務?

      ①墨菲定律(設計系統)和康威定律(系統劃分)

      康威定律,是一個五十多年前就被提出來的微服務概念。在康威的這篇文章中,最有名的一句話就是:

      Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
      -Melvin Conway(1967)

      中文直譯大概的意思就是:設計系統的組織,其產生的設計等同于組織之內、組織之間的溝通結構。

      看看下面的圖片,再想想 Apple 的產品、微軟的產品設計,就能形象生動的理解這句話。

      感興趣的各位可以研究一下!

      ②架構演化

      架構是不斷演化出來的,微服務也是這樣,當從各大科技公司,規模大到一定程度,完全需要演化成更進一步管理的技術架構體系。

      傳統的團隊,都是面向過程化的,產品想完了去找策劃,策劃完了找開發,接著順著一步一步找。

      我們做技術都是為了產品的,一旦過程出來了什么問題,回溯尋找問題會非常耗時。

      使用了微服務架構體系,團隊組織方式需要轉變成跨職能團隊,即每個團隊都有產品專家,策劃專家,開發專家,運維專家,他們使用 API 方式發布他們的功能,而平臺使用他們的功能發布產品。

      微服務技術架構體系

      下面我分享一下大部分公司都使用的微服務技術架構體系:

      服務發現

      主流的服務發現,分為三種:

      第一種,開發人員開發了程序以后,會找運維配一個域名,服務的話通過 DNS 就能找到我們對應的服務。

      缺點是,由于服務沒有負載均衡功能,對負載均衡服務,可能會有相當大的性能問題。

      第二種,是目前普遍的做法??梢詤⒖?Zuul 網關,每一個服務都通過服務端內置的功能注冊到注冊中心,服務消費者不斷輪詢注冊中心發現對應的服務,使用內置負載均衡調用服務。

      缺點是,對多語言環境不是很好,你需要單獨給消費者的客戶端開發服務發現和負載均衡功能。當然了,這個方法通常都是用在 Spring Cloud 上的。

      第三種,是將客戶端和負載均衡放在同一個主機,而不是同一個進程內。

      這種方法相對第一種第二種方法來說,改善了他們的缺點,但是會極大增加運維成本。

      網關

      微服務的網關是什么?我們可以聯系生活實際想一下。每一個大的公司,都會有一偏屬于自己的建筑區,而這建筑區內,都有不少的門衛。如果有外來人員進入公司,會先和門衛打好招呼,才能進去。

      將生活實際聯系到微服務上,就不難理解網關的意思了:

      網關的作用如下:

      • 反向路由:很多時候,公司不想讓外部人員看到我們公司的內部,就需要網關來進行反向路由。即將外部請求轉換成內部具體服務調用。
      • 安全認證:網絡中會有很多惡意訪問,譬如爬蟲,譬如黑客攻擊,網關維護安全功能。
      • 限流熔斷:當請求很多服務不堪重負,會讓我們的服務自動關閉,導致不能用服務。限流熔斷可以有效的避免這類問題。
      • 日志監控:所有的外面的請求都會經過網關,這樣我們就可以使用網關來記錄日志信息。
      • 灰度發布,藍綠部署。是指能夠平滑過渡的一種發布方式。在其上可以進行 A/B testing。

        即讓一部分用戶繼續用產品特性 A,一部分用戶開始用產品特性 B,如果用戶對 B 沒有什么反對意見,那么逐步擴大范圍,把所有用戶都遷移到 B 上面來。

      開源網關 Zuul 架構:

      Zuul 網關核心其實是一個 Servlet,所有請求都會經過 Zuul Servlet 傳到 ZuulFilter Runner,然后分發到三種過濾器。

      先說說架構圖左半部分,分別是使用 Groovy 實現的前置路由過濾器,路由過濾器,后置路由過濾器。

      一般請求都會先經過前置路由過濾器處理,一般的自定義 Java 封裝邏輯也會在這里實現。

      路由過濾器,實現的是找到對應的微服務進行調用。調用完了,響應回來,會經過后置路由過濾器,通過后置路由過濾器我們可以封裝日志審計的處理。

      可以說 Zuul 網關最大的特色就是它的三層過濾器。架構圖右半部分,是 Zuul 網關設計的自定義過濾器加載機制。

      網關內部會有生產者消費者模型,自動的將過濾器腳本發布到 Zuul 網關讀取加載運行。

      配置中心

      以前,開發人員把配置文件放在開發文件里面,這樣會有很多隱患。譬如,配置規范不同,無法追溯配置人員。

      一旦需要大規模改動配置,改動時間會很長,無法追溯配置人員,從而影響整個產品,后果是我們承擔不起的。

      因此就有配置中心這個嘍!現在的開源中心有百度配置中心 Disconf,Spring Cloud Config,Apollo。

      今天重點說說現在應用質量不錯的配置中心,攜程開源的阿波羅(Apollo):

      Apollo 的配置中心規模比較大,本地應用會有響應的配置中心客戶端,可以定時同步配置中心里的配置。如果配置中心怠機,會使用緩存來進行配置。

      通訊方式

      關于通訊方式,一般市面也就是兩種遠程調用方式,我整理了一個表格:

      監控預警

      監控預警對于微服務很重要,一個可靠的監控預警體系對微服務運行至關重要。

      一般監控分為如下層次:

      從基礎設施到用戶端,層層有監控,全方位,多角度,每一個層面都很重要。

      總體來說,微服務可分為 5 個監控點:

      • 日志監控
      • Metrics 監控
      • 健康檢查
      • 調用鏈檢查
      • 告警系統

      ①監控架構

      下面的圖是大部分公司的一種監控架構圖。每一個服務都有一個 Agent,Agent 收集到關鍵信息,會傳到一些 MQ 中,為了解耦。

      同時將日志傳入 ELK,將 Metrics 傳入 InfluxDB 時間序列庫。而像 Nagios,可以定期向 Agent 發起信息檢查微服務。

      ②調用鏈監控 APM

      很多公司都有調用鏈監控,就譬如阿里有鷹眼監控,點評的 Cat,大部分調用鏈監控(沒錯,我指的 Zipkin)架構是這樣的:

      當請求進入 Web 容器的時候,會經過創建 Tracer,連接 Spans(模擬潛在的分布式工作的延遲,該模塊還包含在系統網絡間傳遞跟蹤上下文信息的工具包,如通過 HTTP Headers)。

      Spans 有一個上下文,其中包含 Tracer 標識符,將其放在表示分布式操作的樹的正確位置。

      當我們把圖中的各種 Span 放到后端的時候,我們的服務調用鏈會動態的生成調用鏈。

      下面是一些市場上用的比較多的調用鏈監控對比:

      熔斷、隔離、限流、降級

      面對巨大的突發流量下,大型公司一般會采用一系列的熔斷(系統自動將服務關閉防止讓出現的問題最大化)、隔離(將服務和服務隔離,防止一個服務掛了其他服務不能訪問)、限流(單位時間內之允許一定數量用戶訪問)、降級(當整個微服務架構整體的負載超出了預設的上限閾值或即將到來的流量預計將會超過預設的閾值時,為了保證重要或基本的服務能正常運行,我們可以將一些不重要或不緊急的服務或任務進行服務的延遲使用或暫停使用)措施。

      下面介紹一下 Hystrix 的運行流程:

      每一個微服務調用時,都會使用 Hystrix 的 Command 方式(上圖的左上角那個),然后使用 Command 同步的,或者是響應式的,或者是異步的,判斷電路是否熔斷(順著圖從左往右看),如果斷路則走降級 Fallback。

      如果這個線閉合著,但是線程資源沒了,隊列滿了,則走限流措施(看圖的第 5 步)。

      如果走完了,執行成功了,則走 run() 方法,獲取 Response,但是這個過程如果出錯了,則繼續走降級 Fallback。

      同時,看圖最上面有一個后綴是 Health 的,這是一個計算整個鏈路是否健康的組件,每一步操作都被它記錄著。

      容器與服務編排引擎

      從物理機到虛擬機,從虛擬機到容器;從物理集群到 OpenStack,OpenStack 到 Kubernetes;科技不斷的變化,我們的認知也沒刷新。

      我們從容器開始說起,它首先是一個相對獨立的運行環境,在這一點有點類似于虛擬機,但是不像虛擬機那樣徹底。

      虛擬機會將虛擬硬件、內核(即操作系統)以及用戶空間打包在新虛擬機當中,虛擬機能夠利用“虛擬機管理程序”運行在物理設備之上。

      虛擬機依賴于 Hypervisor,其通常被安裝在“裸金屬”系統硬件之上,這導致 Hypervisor 在某些方面被認為是一種操作系統。

      一旦 Hypervisor 安裝完成, 就可以從系統可用計算資源當中分配虛擬機實例了,每臺虛擬機都能夠獲得唯一的操作系統和負載(應用程序)。

      簡言之,虛擬機先需要虛擬一個物理環境,然后構建一個完整的操作系統,再搭建一層 Runtime,然后供應用程序運行。

      對于容器環境來說,不需要安裝主機操作系統,直接將容器層(比如 LXC 或 Libcontainer)安裝在主機操作系統(通常是 Linux 變種)之上。

      在安裝完容器層之后,就可以從系統可用計算資源當中分配容器實例了,并且企業應用可以被部署在容器當中。

      但是,每個容器化應用都會共享相同的操作系統(單個主機操作系統)。容器可以看成一個裝好了一組特定應用的虛擬機,它直接利用了宿主機的內核,抽象層比虛擬機更少,更加輕量化,啟動速度極快。

      相比于虛擬機,容器擁有更高的資源使用效率,因為它并不需要為每個應用分配單獨的操作系統——實例規模更小、創建和遷移速度也更快。這意味著相比于虛擬機,單個操作系統能夠承載更多的容器。

      云提供商十分熱衷于容器技術,因為在相同的硬件設備當中,可以部署數量更多的容器實例。

      此外,容器易于遷移,但是只能被遷移到具有兼容操作系統內核的其他服務器當中,這樣就會給遷移選擇帶來限制。

      因為容器不像虛擬機那樣同樣對內核或者虛擬硬件進行打包,所以每套容器都擁有自己的隔離化用戶空間,從而使得多套容器能夠運行在同一主機系統之上。

      我們可以看到全部操作系統層級的架構都可實現跨容器共享,惟一需要獨立構建的就是二進制文件與庫。

      正因為如此,容器才擁有極為出色的輕量化特性。我們最常用的容器是 Docker。

      ①容器編排

      過去虛擬機可以通過云平臺 OpenStack 管理虛擬化,容器時代如何管理容器呢?這就要看看容器編排引擎了。

      Apache Mesos:Mesos 是基于 Master,Slave 架構,框架決定如何利用資源,Master 負責管理機器,Slave 會定期的將機器情況報告給 Master,Master 再將信息給框架。Master 是高可用的,因為 ZK,也有 Leader 的存在。

      下面是架構圖:

      Kubernetes:Kubernetes 是最近十分火熱的開源容器編排引擎,具體可以參考前幾天分享的一篇文章《我花了10個小時,寫出了這篇K8S架構解析》:

      Kubernetes 設計理念和功能其實就是一個類似 Linux 的分層架構,先說說每一個 Kubernetes 節點內部,kubelet 管理全局全局 pod,而每一個 pod 承載著一個或多個容器,kube-proxy 負責網絡代理和負載均衡。

      Kubernetes 節點外部,則是對應的控制管理服務器,負責統一管理各個節點調度分配與運行。

      ②服務網格化

      關于服務網絡化,后面會更加深入的為大家進行講解。

      資料與文獻:

      • 馬丁.福勒對微服務的描述
      • 微服務架構的理論基礎 - 康威定律
      • 調用鏈選型之Zipkin,Pinpoint,SkyWalking,CAT
      標簽:容器 架構 網關
      淺談SQL Server的內部運行機制
      ? 上一篇 2022-08-18
      如何繪制架構圖(包括知識圖譜)
      下一篇 ? 2022-08-18
      • 如何在Ubuntu中保留文件系統并備份當前開發板鏡像
        0閱讀 0條評論 個贊
        在Ubuntu保留文件系統或者說備份當前開發板鏡像的需求在不斷增加。比如Ubuntu文件系統需要安裝庫文件的話直接使用apt-get工具就可以下載,但由于需要下載的核心板較多,比較費時間,這時需要將安……
      • 國產核心板全志T507助力消防系統升級
        0閱讀 0條評論 個贊
        9月16日下午,位于湖南長沙市區內的中國電信大樓發生火災,建筑高度218米,現場濃煙滾滾,數十層樓體燃燒劇烈。消防救援人員趕到現場后很快將火勢控制住,目前大樓火勢已被撲滅,所幸未發現人員傷亡。湖南電信……
      • 教大家如何處理Spring Boot易流中的用戶和群體!
        0閱讀 0條評論 個贊
        1.準備工作2.用戶操作2.1添加用戶2.2修改用戶2.3刪除用戶2.4查詢用戶3.組操作3.1添加組3.2修改組3.3刪除組3.4查詢組4.查看表詳情雖然說我們在實際開發中,……
      • 從PG15開始WAL壓縮優化
        0閱讀 0條評論 個贊
        PG15傳聞中的超級令人激動的功能大多數跳票了,年初我也寫過一個關于PG15新功能跳票的文章。PG15BETA已經發出幾個月了,似乎PG15里令人激動人心的功能不多,不過從長長的新功能列表里,……
      • 深入了解美團葉子發射器開源方案
        0閱讀 0條評論 個贊
        大家好,我是樹哥。之前我們有聊過「如何設計一個分布式ID發號器」,其中有講過4種解決方案,分別是:UUID類雪花算法數據庫自增主鍵Redis原子自增美團以第2、3種解決方案為基礎,開發出……
      發表評論 共有條評論
      用戶名: 密碼:
      驗證碼: 匿名發表
      • 大促銷活動如何抵御高流量DDoS攻擊?
        0閱讀 0條評論 個贊
        大促活動如何抵御大流量DDoS攻擊?每一次活動大促帶來的迅猛流量,對技術人而言都是一次嚴峻考驗。如果在活動期間遭受黑產惡意DDoS攻擊,無疑是雪上加霜。電商的特性是業務常態下通常不會遭受大流量DD……
      • SQL Server 2005分區模板和實例
        0閱讀 0條評論 個贊
        一、場景這一段時間使用SQLServer2005對幾個系統進行表分區,這幾個系統都有一些特點,比如數據庫某張表持續增長,給數據庫帶來了很大的壓力?,F在假如提供一臺新的服務器,那么我們應該如何規劃……
      • 金牛座入門 MVC微服務框架開發教程
        0閱讀 0條評論 個贊
        前言:對于Taurus.MVC的微服務的注冊中心而言:什么樣的應用中心,有權利注冊服務?什么樣的網關中心,有權利調取服務列表?在默認沒有進行相關配置時,只要引用Taurus.MVC的框架,都擁有該權限……
      • Java內存區(運行時數據區)簡介
        0閱讀 0條評論 個贊
        Java虛擬機在執行Java程序的過程中會把它管理的內存劃分成若干個不同的數據區域。JDK1.8和之前的版本略有不同。下圖是JDK1.8對JVM做的改動,把方法區的具體實現----元空……
      • MQ系列5:5的發送模式:RocketMQ消息
        0閱讀 0條評論 個贊
        在之前的篇章中,我們學習了RocketMQ的原理,以及RocketMQ中命名服務ServiceName的運行流程,本篇從消息的生產、消費來理解一條消息的生命周期。1消息生產在RocketMQ中……
      • Java開源數據庫引擎 數據庫計算封閉的一站式解決方案
        0閱讀 0條評論 個贊
        目錄前言引入一、數據庫封閉性帶來的問題?問題1:ETL變成ELT甚至LETETL:ELT:問題2:中間表帶來的資源消耗和耦合問題3:多樣性數據源問題4:存儲過程帶來的安全和耦合問題問題5:大……
      • SpringMVC 01: SpringMVC第一個SpringMVC項目
        0閱讀 0條評論 個贊
        SpringMVCSpringMVC概述:是基于MVC開發模式的框架,用來優化控制器是Spring家族的一員,也具備IOC和AOP什么是MVC:它是一種開發模式,是模型視圖控制器的簡稱,所有的web應……
      • 滲透攻擊和防御網絡-簡單的SQL注入
        0閱讀 0條評論 個贊
        1背景京東SRC(SecurityResponseCenter)收錄大量外部白帽子提交的sql注入漏洞,漏洞發生的原因多為sql語句拼接和Mybatis使用不當導致。2手工檢測2.1前置知識……
      • 卡夫卡詳解(一)——卡夫卡是什么 怎么用
        0閱讀 0條評論 個贊
        kafka是什么在回答這個問題之前,我們需要先了解另一個東西--eventstreaming。什么是eventstreaming我覺得,eventstreaming是一個動態的概念,它描述了一……
      • 企業操作和維護實踐-丟棄docker構建
        15閱讀 0條評論 個贊
        本章目錄目錄0x00前言簡述快速介紹什么是Kaniko?為啥用Kaniko?Kaniko是如何工作的?Kaniko已知功能問題kaniko構建上下文kaniko緩存構建0x01部署使用環境……
      • Java線程面試題前50名
        0閱讀 0條評論 個贊
        .css-1yuhvjn{margin-top:16px;}.css-3jt6os.FileLinkCard{-webkit-align-items:center;-webkit-box-align……
      • Velox簡介:一個開源的統一執行引擎
        0閱讀 0條評論 個贊
        ?Meta正在引入Velox,這是一個開源的統一執行引擎(unifiedexecutionengine),旨在加速數據管理系統和簡化其開發。?Velox正在積極開發中,Meta在2022……
      • 二戰MySQL數據庫【升華】
        0閱讀 0條評論 個贊
        MYSQL入門系列——第二篇1.篩選條件:(1)比較運算符:(2)邏輯運算符:(3)其他操作:1.排序:2.限制:拓展:3.去重:4.模糊查詢:(like'%')5.范圍查詢:2.聚合與分組(重點……
      • 與docker卷一起安裝的注意事項
        0閱讀 0條評論 個贊
        目錄Content使用數據卷(volume)使用掛載點(共享宿主目錄,bindmount)目錄兼容性可移植性目錄替代相關指定位置--volume與--mount區別鏡像保存docker-compos……
      • 淺談SQL Server中統計對查詢的影響
        4閱讀 0條評論 個贊
        簡介SQLServer查詢分析器是基于開銷的。通常來講,查詢分析器會根據謂詞來確定該如何選擇高效的查詢路線,比如該選擇哪個索引。而每次查詢分析器尋找路徑時,并不會每一次都去統計索引中包含的行數,值……
      • SQL Server:觸發器的詳細說明
        0閱讀 0條評論 個贊
        1.概述2.觸發器的分類3.Inserted和Deleted表4.觸發器的執行過程5.創建觸發器6.修改觸發器:7.刪除觸發器:8.查看數據庫中已有觸發器:9.“Insteadof……
      • 談ASP.NET核心認證與授權
        0閱讀 0條評論 個贊
        使用asp.netcore開發應用系統過程中,基本上都會涉及到用戶身份的認證,及授權訪問控制,因此了解認證和授權流程也相當重要,下面通過分析asp.netcore框架中的認證和授權的源碼來分析……
      • 國產核心板全志T507助力消防系統升級
        0閱讀 0條評論 個贊
        9月16日下午,位于湖南長沙市區內的中國電信大樓發生火災,建筑高度218米,現場濃煙滾滾,數十層樓體燃燒劇烈。消防救援人員趕到現場后很快將火勢控制住,目前大樓火勢已被撲滅,所幸未發現人員傷亡。湖南電信……
      • Go語言知識|基本數據類型
        0閱讀 0條評論 個贊
        前言學習Go半年之后,我決定重新開始閱讀《TheGoProgramingLanguage》,對書中涉及重點進行全面講解,這是Go語言知識查漏補缺系列的文章第二篇,前一篇文章則對應書中一二兩章。我……
      • spring接口有多個實現類 應該給哪個注入這個依賴?
        0閱讀 0條評論 個贊
        一、問題的描述在實際的系統應用開發中我經常會遇到這樣的一類需求,相信大家在工作中也會經常遇到:同一個系統在多個省份部署。一個業務在北京是一種實現方式,是基于北京用戶的需求。同樣的業務在上海是另外一種實……
      最近發布資訊
      更多
      警花高潮嗷嗷叫
      <del id="nnjnj"></del><track id="nnjnj"></track>

      <p id="nnjnj"></p>

      <address id="nnjnj"></address>

        <pre id="nnjnj"><pre id="nnjnj"></pre></pre>

          <noframes id="nnjnj"><ruby id="nnjnj"><ruby id="nnjnj"></ruby></ruby>