微服務架構的理解以及和 RPC 的關係(理論篇)

全網第一菜雞發表於2020-07-04

什麼是微服務架構?

微服務是一種架構概念,旨在透過將功能分解到各個離散的服務中已實現對解決的解耦。你可以將其看作是在架構層次而非獲取服務的類上應用很多SOLID原則。微服務架構是一個很有趣的概念,它的主要作用是將功能分解到離散的各個服務中,從而降低系統的耦合性,並提供更加靈活的服務支援。
概念:把一個大型的單個應用程式和服務拆分為數個甚至數十個的支援服務,它可擴充套件單個元件而不是整個的應用程式堆疊,從而滿足服務等級協議。
定義:圍繞業務領域元件來建立應用,這些應用可以獨立的進行開發,管理,和迭代。在分散的元件中使用雲架構和平臺式部署,管理和服務功能。使產品交付變得更加簡單。
本質:用一些功能比較明確,業務比較精煉的服務區解決更大,更實際的問題

微服務架構的優點

有效的拆分應用,實現敏捷開發和部署
分工不同,以前我們可能是一人一個模組,現在可能是一人一個系統
架構不同,服務的拆分是一個技術含量很高的問題,拆分是否合理對以後發展影響巨大
部署方式不同,如果還像以前一樣部署估計累死了,自動化運維不可不上
容災不同,好的微服務可以隔離故障避免服務整體垮掉,壞的微服務設計仍然可以因為一個子服務出現問題導致連鎖反應
擴充套件不同,微服務更容易按需求進行橫向和縱向擴充套件

微服務做的事情是按照專案顆粒度進行服務的拆分,把模組單獨拿出來做成每一個單獨的小專案。微服務的主要特點有:
每一個功能模組是一個小專案,獨立執行在不同程式或者機器上,不同功能可以由不同的人員開發獨立開發,獨立部署不需要依賴整體專案就可以啟動單個服務,分散式管理,每個服務做好自己的事情就好,設計微服務時需要考慮資料庫,是所有服務公用一個資料庫還是一個服務一個資料庫。

微服務的缺點

因為微服務架構的複雜度,對技術要求高,所以要考慮團隊是否已經具備相關技術
公司業務是否適合進行微服務改造,並不是都一定適合,傳統行業有很多複雜的垂直的業務架構。
微服務生態的技術又很多,並不是每一個技術方案都需要用上,適合自己的才是最好的

     對於微服務架構:技術上不是問題,意識比工具重要!

什麼是RPC?

很多傳統的phper並不懂什麼是rpc,RPC全稱Remote Procedure Call,中文譯為遠端過程呼叫,其實你可以把它理解為一種架構性上的設計,或者是一種解決方案。
透過RPC我們可以像呼叫本地方法一樣呼叫別的機器上的方法,使用者將無感伺服器之間的通訊,RPC在微服務中起到了相當大的作用

本作品採用《CC 協議》,轉載必須註明作者和本文連結

相關文章