服务层

服务层的主要目标其实就是为了降低系统间相互关联的复杂度。

一、配置中心

在系统中，将数据库配置写在代码中，使得数据与代码耦合性太高，使得每次改代码，都要重新打包；将配置信息放配置文件中，使得数据与代码耦合性降低；随着并发量增大，需要扩充服务器，使得每个服务器都要进行数据库配置、部署；若再修改此配置，工作量非常大，还可能因为时间造成不一致情况。所以要将配置文件放在配置中心统一管理。
具体做法：

• 将所有服务器上的该配置文件删除

• 将一个地方创建一个该配置文件

• 将所有服务器上的应用的配置源改为此地方的此配置文件，这个地方被称为配置中心，这个文件被称为中心配置文件

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bbzf1Sd9-1582559181662)(https://user-images.githubusercontent.com/56629574/74003032-24deb880-49ac-11ea-8ee2-93a9cb96526d.png)]
完美：目前应用，不用改源码、不用重启、支持高并发、没有在每个服务器上更改配置的冗余操作
对于单机版，我们称之为配置（文件）；对于分布式集群系统，将配置文件抽取出核心配置文件，我们称之为配置中心（系统）
参考：https://www.cnblogs.com/yelao/p/10741156.html
比如分布式配置中心：nacos
下面是配置中心简单的设计，其中通过“系统标识 + host + port”来标识唯一一个系统运行实例是常见的设计方法。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QjlvIrf4-1582559181667)(https://user-images.githubusercontent.com/56629574/74003313-1c3ab200-49ad-11ea-8387-5f2b1007a243.png)]

二、服务中心

系统间调用可以直接通过配置文件记录在系统内部，但当系统数量多了以后，就会存在问题。
比如10个系统依赖A系统的X接口，需要将其改成Y接口，则10个系统的几十台机器的配置都要修改、重启。
服务中心就是为了解决跨系统依赖的配置和调度问题。
服务中心的实现一般来说有两种方式：

• 服务名字系统（Service Name System）
  相信你会立刻联想到DNS，即Domain Name System。没错，两者的性质是基本类似的。DNS的作用将域名解析为IP地址，主要原因是我们记不住太多的数字IP，域名就容易记住。服务名字系统是为了将Service名称解析为“host + port + 接口名称”，但是和DNS一样，真正发起请求的还是请求方。基本的设计如下：
  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Cwz5h2Wg-1582559181669)(https://user-images.githubusercontent.com/56629574/74004804-d92f0d80-49b1-11ea-9d4c-e81345b8db94.png)]
• 服务总线系统（Service Bus System）
  由总线系统完成调用，服务请求方都不需要直接和服务提供方交互了。
  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JYGCJXcm-1582559181670)(https://user-images.githubusercontent.com/56629574/74004954-5195ce80-49b2-11ea-856a-f8dd05884fb3.png)]

三、消息队列

业界已经有很多成熟的开源实现方案，如果要求不高，基本上拿来用即可，例如，RocketMQ、Kafka、ActiveMQ等。
应用场景介绍：
1. 异步处理
用户注册后，需要发注册邮件和注册短信。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-enUBYPKF-1582559181671)(https://user-images.githubusercontent.com/56629574/74009178-a4c14e80-49bd-11ea-978e-d27cd784fa32.png)]

2. 应用解耦
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gx0SOq67-1582559181672)(https://user-images.githubusercontent.com/56629574/74006746-9cfeab80-49b7-11ea-9921-53a76c1fe9b5.png)]
下单操作涉及订单系统和库存系统。当串行处理时若库存失败，导致订单失败。所以解耦后订单写入消息队列就不再关心后续操作了。
3. 流量削峰
秒杀活动是希望更多人参与，但抢购时间到达，用户真正下单时，服务器并不希望有几百万同时发起抢购请求。在日常上下班高峰场景中，是通过错峰限行方案，在线上的秒杀活动中也是类似的解决方案，平安度过同时抢购的流量峰值问题。
削峰的本质是更多的延缓用户请求，以及层层过滤用户的访问需求，遵从“最后落地到数据库的请求数要尽量少”的原则。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9OmBM82s-1582559181673)(https://user-images.githubusercontent.com/56629574/74007977-a9d0ce80-49ba-11ea-8958-0fd006ec71af.png)]
4. 日志处理
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Re0PEee8-1582559181675)(https://user-images.githubusercontent.com/56629574/74008532-13051180-49bc-11ea-9465-d08e8d1bd9cb.png)]
5. 消息通讯
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8FHxPhlt-1582559181676)(https://user-images.githubusercontent.com/56629574/74008830-d7b71280-49bc-11ea-9f35-0e027ea49ec4.png)]