微服务架构
微服务的概念由 Martin Fowler 于2014年3月提出：
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务和服务之间采用轻量级的通信机制相互沟通。每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。
下图是一个电商系统的微服务架构图：
微服务架构与单体应用相比，具有以下优点：
1、每个服务都比较简单，只关注于一个业务功能；
2、微服务架构方式是松耦合的，每个服务可以独立测试、部署、升级、发布；
3、每个微服务可由不同团队独立开发，可以各自选择最佳及最合适的不同的编程语言与工具；
4、每个服务可以根据需要进行水平扩展，提高系统并发能力。
没有银弹，微服务架构在带来诸多优点的同时，也会有如下缺点：
1、微服务架构提高了系统的复杂度，增加了运维开销及成本。如单体应用可能只需部署至一小片应用服务集群，而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务，并可能需要支持多种语言和环境；
2、作为一种分布式系统，微服务架构引入了其他若干问题，例如消息序列化、网络延迟、异步机制、容错处理、服务雪崩等；
3、服务管理的复杂性，如服务的注册、发现、降级、熔断等问题；
4、服务与服务之间存在相互调用的情况，为排查系统故障带来巨大挑战。
可以说，正是传统应用架构的系统变得日益臃肿，面临难以维护、扩展的问题，同时容器化技术（Docker）的蓬勃发展和 DevOps 思想的日渐成熟，催生了新的架构设计风格 – 微服务架构的出现。
RPC 框架
微服务架构中的各个服务通常不在同一个机器上，甚至不会在同一个网络环境里，因此微服务之间如何调用是一个亟待解决的问题，我们通常使用 RPC 协议来解决：
RPC（Remote Procedure Call），即远程过程调用，是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。——维基百科
实现了 RPC 协议的框架，可以让服务方和调用方屏蔽各种底层细节，让调用方像调用本地函数一样调用远端的函数（服务）。RPC 框架一般为服务端和客户端提供了序列化、反序列化、连接池管理、负载均衡、故障转移、队列管理、超时管理、异步管理等职能。在网上找到一个说明 RPC 框架工作原理图：
目前，根据序列化数据时采用的技术的不同，可分为 J6来源gaodaimacom搞#^代%!码网搞gaodaima代码SON-RPC 和 gRPC 两种：
1、JSON-RPC 是一种基于 JSON 格式的轻量级的 RPC 协议标准，可基于 HTTP 协议来传输，或直接基于 TCP 协议来传输。 JSON-RPC 优点是易于使用和阅读。
2、gRPC 是一个高性能、通用的开源 RPC 框架，其由 Google 主要面向移动应用开发并基于 HTTP/2 协议标准而设计，基于 ProtoBuf (Protocol Buffers) 序列化协议开发，且支持众多开发语言。 gRPC 具有低延迟、高效率、高扩展性、支持分布式等优点。
转载请注明原文链接：PHP 微服务集群搭建 – Hyperf
