这是我参与「第三届青训营 -后端场」笔记创作活动的的第5篇笔记。
架构，又称为软件架构，是有关软件整体结构与组件的抽象描述，用于指导软件系统各个方面的设计。后端的架构有比较简单的单体架构，这样做的缺点是运维的时候需要下线服务，且难以扩展。（图片来源于网络）
于是就有水平切分、垂直切分等做法，以便服务可以更方便地分布式部署，逐渐演变出现了现在广泛使用的微服务架构：
不同的服务之间进行了足够细的拆分，这样就可以针对单独的服务进行调度、扩容。同时，一些服务的故障也不会牵连到整个业务下线。缺点是运维的难度上升了。
RPC
微服务架构中，不同服务间的调用称为RPC（Remote Procedure Calls）。因为服务往往部署在不同的服务器上，那么服务间的调用就需要通过网络通信。RPC需要解决函数间如何映射，数据编解码，网络传输的问题。（容器化的情况下，一些联系紧密的服务也可以尽量调度到一台服务器上，这样就可以通过IPC通信，不经过网络效率更高。）
在RPC框架的帮助下，服务间的调用就如通调用函数一样，但是要考虑网络通信的影响。
服务注册与发现
每一类服务都有许多个实例，那么当A服务的一个实例需要调用B服务提供的功能时，就需要获取B服务的一个实例地址，不然无法进行RPC通信。如果直接将B服务的实例地址都储存在A服务的实例中，那么如果B服务有实例下线，则需要修改所有A实例中存储的地址，且难以实现负债均衡。
因此，需要引入一个统一的服务注册中心进行管理。中心中储存着每一类服务中每一个实例的地址。当新的实例上线时，将其注册到中心进行管理即可。当需要调用某一服务时，向中心请求获得实例的地址进行调用。同时，服务注册中心也可以通过一些算法均衡同一类别服务中的实例的负载。
