第3章 服务框架

服务框架是系统从集中式过渡到分布式的基础服务和条件，需要在分布式系统之前就迁移、准备完毕；服务框架是解决应用服务化的问题

3.1 网站功能持续丰富后的困境和应对

一个网站在经历一个快速发展的时期，当每天有百万级别的有效访问量(购网网站的成交单数量)；系统基本会演化成下面的系统：

系统按照功能分成几个“巨大”的应用，每个应用都可以访问底层的基础系统；比如db/分布式缓存、搜索系统、分布式文件系统,应该说这样的结构足够的清晰、简单、解决大部分问题.

 但是随着访问量的持续增加，最简单的方式是增加应用的机器，但是这样会增加DB 的压力，因为主要一台DB 支撑写，所以最终还是要进行DB中间件进行分库、分表；随着开发人员越来越多，每个应用的代码也变的无比巨大、臃肿；很多重复、冗余的代码。这样就会采取分拆应用的方案，应用分拆有2种方案：

• 简单的分拆应用，所有应用都直接访问底层系统

  这样的分拆简单，但不能解决数据库的连接压力和代码重复、冗余的问题，所以采用下面的一种方案

• 在应用和底层系统中间加上一层服务层

这就是我们说的服务化的方案，在应用层和底层数据库层加上服务层，真正系统中服务层可能是多层，彼此之间可以相互调用。

服务化的优点：－-> 可以理解为微服务化

• 从整体结构上看：架构更清晰、更立体
• 稳定性上看：散落在各个应用中重复的代码也变成了服务，有统一的团队进行维护；保证代码的质量
• 因为服务的代码稳定、发布次数也会变少或者限制，一定程度上也增加了系统的稳定性
• 底层的系统资源也由服务层统一管理，结构清晰、提高效率
• 高扩展性：随着业务的发展，应用数量会越来越多，服务化后可以让应用更加快速的开发 【中台策略】

3.2 服务框架的设计与实现

3.2.1 应用从集中式走向分布式遇到的问题

先来看看服务框架要解决的问题：

在做服务框架时，我们用的最基础的知识是网络通信，在远程网络通信时我们需要把发送的数据进行编码，服务端收到请求数据先解码然后进行相关的处理；

• 单机单进程的调用

•  远程服务、调用客户端

• 服务端的伪代码实现：

3.2.2 RPC 调用的流程方式