服务层的主要目标其实就是为了降低系统间相互关联的复杂度。
一、配置中心
在系统中，将数据库配置写在代码中，使得数据与代码耦合性太高，使得每次改代码，都要重新打包；将配置信息放配置文件中，使得数据与代码耦合性降低；随着并发量增大，需要扩充服务器，使得每个服务器都要进行数据库配置、部署；若再修改此配置，工作量非常大，还可能因为时间造成不一致情况。所以要将配置文件放在配置中心统一管理。
具体做法：
将所有服务器上的该配置文件删除
将一个地方创建一个该配置文件
将所有服务器上的应用的配置源改为此地方的此配置文件，这个地方被称为配置中心，这个文件被称为中心配置文件
完美：目前应用，不用改源码、不用重启、支持高并发、没有在每个服务器上更改配置的冗余操作
对于单机版，我们称之为配置（文件）；对于分布式集群系统，将配置文件抽取出核心配置文件，我们称之为配置中心（系统）
参考：https://www.cnblogs.com/yelao/p/10741156.html
比如分布式配置中心：nacos
下面是配置中心简单的设计，其中通过“系统标识 + host + port”来标识唯一一个系统运行实例是常见的设计方法。
二、服务中心
系统间调用可以直接通过配置文件记录在系统内部，但当系统数量多了以后，就会存在问题。
比如10个系统依赖A系统的X接口，需要将其改成Y接口，则10个系统的几十台机器的配置都要修改、重启。
服务中心就是为了解决跨系统依赖的配置和调度问题。
服务中心的实现一般来说有两种方式：
- 服务名字系统（Service Name System）
相信你会立刻联想到DNS，即Domain Name System。没错，两者的性质是基本类似的。DNS的作用将域名解析为IP地址，主要原因是我们记不住太多的数字IP，域名就容易记住。服务名字系统是为了将Service名称解析为“host + port + 接口名称”，但是和DNS一样，真正发起请求的还是请求方。基本的设计如下：
- 服务总线系统（Service Bus System）
由总线系统完成调用，服务请求方都不需要直接和服务提供方交互了。
三、消息队列
业界已经有很多成熟的开源实现方案，如果要求不高，基本上拿来用即可，例如，RocketMQ、Kafka、ActiveMQ等。
应用场景介绍：
1. 异步处理
用户注册后，需要发注册邮件和注册短信。
2. 应用解耦
下单操作涉及订单系统和库存系统。当串行处理时若库存失败，导致订单失败。所以解耦后订单写入消息队列就不再关心后续操作了。
3. 流量削峰
秒杀活动是希望更多人参与，但抢购时间到达，用户真正下单时，服务器并不希望有几百万同时发起抢购请求。在日常上下班高峰场景中，是通过错峰限行方案，在线上的秒杀活动中也是类似的解决方案，平安度过同时抢购的流量峰值问题。
削峰的本质是更多的延缓用户请求，以及层层过滤用户的访问需求，遵从“最后落地到数据库的请求数要尽量少”的原则。
4. 日志处理
5. 消息通讯