微服務rpc

1. php rpc好用嗎,有什麼優缺點php rpc框架哪個好

rpc的使用只能說因地制宜吧,例如與硬體通訊.至於開發的話,你可以用swoole擴展或者grpc.

2. 如何使用bbo 實現微服務集群

一個高內聚版本，所有功能部署在一起。數據訪問框架（orm）成為關鍵。這個架構很少被人使用，幾乎接近滅絕了吧。
優點：成本低，適合功能少又簡單 缺點：很多，比如無法適應高流量，二次開發難，部署成本高

3. Java使用微服務，分布式

消息隊列了解下啊

4. 微服務有哪些特點

相比於傳統集中式的應用系統，微服務的優點：

• 每個服務獨立存在，所以可以單獨部署，不用每次發布某個功能都經歷一次全服務發布。

• 遵循單一功能原則，服務之間可以通過RESTFUL或者RPC調用，功能解藕

• 「細粒度」 的高可擴展性，每個服務都可以單獨擴展，單獨負載均衡

• 去中心化，盡可能地實現 「自服務」

• 有利於簡化單獨的開發測試以及部署，對開發團隊友好

微服務缺點：

• 服務的可用性和維護性高度依賴於服務治理，如果治理得不好將會是災難

• 某些服務可能造成性能瓶頸，某些服務的宕機可能導致很多服務受影響

• 服務配置繁瑣

5. 為什麼說要搞定微服務架構，先搞定RPC框架

無論是SOA還是微服務，核心都是RPC框架。如果沒有統一的RPC框架，各個團隊就需要實現自己的一套序列化、反序列化、網路框架、連接池，線程池、超時處理等「業務之外」的重復勞動，所以統一RPC框架，是服務化首先要解決的問題。現階段，外界RPC框架眾多，如果沒有特殊需求，並不需要自研一套。

6. 什麼是微服務

微服務架構是一項在雲中部署應用和服務的新技術。大部分圍繞微服務的爭論都集中在容器或其他技術是否能很好的實施微服務，而紅帽說API應該是重點。
微服務可以在「自己的程序」中運行，並通過「輕量級設備與HTTP型API進行溝通」。關鍵在於該服務可以在自己的程序中運行。通過這一點我們就可以將服務公開與微服務架構（在現有系統中分布一個API）區分開來。在服務公開中，許多服務都可以被內部獨立進程所限制。如果其中任何一個服務需要增加某種功能，那麼就必須縮小進程范圍。在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體進程的架構。

7. 微服務有哪些設計原則

微服務應用4個設計原則：

作為一個原則來講本來應該是個「無狀態通信原則」，在這里我們直接推薦一個實踐優選的Restful 通信風格 ，因為他有很多好處：

當然在有些特殊業務場景下，也需要採用其他的RPC框架，如thrift、avro-rpc、grpc。但絕大多數情況下Restful就足夠用了。

8. 微服務的優點

微服務是指提供單個業務功能的服務，從技術角度看就是一種小而獨立的處理過程，類似流程概念，能夠自行單獨啟動或銷毀，擁有自己獨立的資料庫。

一個復雜軟體架構是由很多這樣小而獨立運行（有自己的埠）微服務組成，這些獨立處理組件之間通訊是通過與語言無關的API進行，簡單協議有同步性質的RMI/RPC和 RESTful Web Services，非同步的消息推送和Reactive方式。

這些模塊化的方式能夠使得公司將項目分解分散到多個開發團隊，跨不同業務部門，提供非常充分的靈活性，幫助提高項目的生命周期，加快項目開發完成效率。

每個微服務組件都有自己分配的存儲 內存和CPU資源，這就使得硬體利用更加易於優化和跟蹤，特別是在基於雲的Pass環境，開發團隊可以使用他們喜歡的技術，任何語言都可以，只要確保微服務之間是可交互的，能夠最終組合起最後的應用。

當管理復雜性會因為採取微服務架構而降低，通常更新其中一個微服務組件不會引起連鎖反應，因為微服務之間是松耦合的。

目前使用微服務的企業有：Netflix Twitter Amazon Web Services (AWS), Google, eBay等。

因為有很多應用和服務部署在基於雲主機的環境中，微服務架構將會嚴重依賴容器技術，容器隔離了微服務處理過程，將一個應用切分為一個個小的實例，這些容器中的小實例有自己的埠和虛擬化環境。

廣泛使用的容器技術是Docker, 一種基於Linux的開源實現，由很多軟體公司支持如 Canonical, Red Hat,和Parallels. PaaS服務支持包括Google App Engine, Red Hat Open Shift,和VMware的 Cloud Foundry,。