PHP微服务集群搭建

1. 每个服务都比较简单，只关注于一个业务功能;
2. 微服务架构方式是松耦合的，每个服务可以独立测试、部署、升级、发布;
3. 每个微服务可由不同团队独立开发，可以各自选择优秀及最合适的不同的编程语言与工具;
4. 每个服务可以根据需要进行水平扩展，提高系统并发能力。

没有银弹，微服务架构在带来诸多优点的同时，也会有如下缺点：

1. 微服务架构提高了系统的复杂度，增加了运维开销及成本。如单体应用可能只需部署至一小片应用服务集群，而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务，并可能需要支持多种语言和环境;
2. 作为一种分布式系统，微服务架构引入了其他若干问题，例如消息序列化、网络延迟、异步机制、容错处理、服务雪崩等;
3. 服务管理的复杂性，如服务的注册、发现、降级、熔断等问题;
4. 服务与服务之间存在相互调用的情况，为排查系统故障带来巨大挑战。

可以说，正是传统应用架构的系统变得日益臃肿，面临难以维护、扩展的问题，同时容器化技术(Docker)的蓬勃发展和 DevOps 思想的日渐成熟，催生了新的架构设计风格 – 微服务架构的出现。

RPC 框架

微服务架构中的各个服务通常不在同一个机器上，甚至不会在同一个网络环境里，因此微服务之间如何调用是一个亟待解决的问题，我们通常使用 RPC 协议来解决：

RPC(Remote Procedure Call)，即远程过程调用，是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。——维基百科

实现了 RPC 协议的框架，可以让服务方和调用方屏蔽各种底层细节，让调用方像调用本地函数一样调用远端的函数(服务)。RPC 框架一般为服务端和客户端提供了序列化、反序列化、连接池管理、负载均衡、故障转移、队列管理、超时管理、异步管理等职能。在网上找到一个说明 RPC 框架工作原理图：

（编辑：长春站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!