SpringCloud之微服务技术栈 大纲

根据业务功能模块将一个单体项目拆分成许多独立的项目 每个项目完成一部分功能 完成独立开发和部署

我们把这个独立的项目称之为一个服务
一个大型项目会有成百上千的服务最终生成一个服务集群

一个请求来了 可能调用服务黄的部分
而服务黄又调用了服务蓝
之后调用了

当业务越来越多 越来越复杂的时候 服务之间的调用关系就会越来越复杂 那这么复杂的关系靠人记录和维护是不可能的 在微服务里有一个组件叫注册中心 它可以记录微服务中每一个服务的ip 端口以及他能干什么事这些信息 当有一个服务调用另外一个服务时 不许哟啊自己记录对方ip 只需要找注册中心就行了 从它那里找对应的服务信息 同时随着服务越来越多 每个服务都有自己的配置文件 将来要更改配置 我们不需要逐一修改 所以在微服务还会有个配置中心 它可以统一管理整个服务集群成千上百的配置 如果以后你有服务需要变更 只需要找到配置中心就好了 他呢会去通知相关的微服务实现配置热更新

当我们服务运行起来以后，用户就可以来访问我们了 这个时候需要一个网关组件 服务器集群有很多微服务 用户怎么知道访问哪一个呢 也不是随便什么人都可以来访问我们的微服务 就相当于小区保安 服务网关 一方面 对用户身份做校验 另一方面 可以把用户请求路由到我们具体服务 这个过程也可以做一些负载均衡 这时候服务集群接受到我们的请求去处理业务 该访问数据库就访问数据库 最后把查询的数据返回给用户

这里数据库画的是一个，将来肯定是集群 不过集群再庞大 肯定没用户多 所以数据库肯定扛不住这样高的并发 因此我们还会加入缓存 缓存将数据库数据放入内存中 内存查询效率肯定比数据库快 而且这种缓存不一定是单体缓存 为了支持高并发 得做成分布式缓存 也是一个集群 因为请求先到缓存 缓存未命中 再去查询数据库 以后业务中还有复杂的搜索 简单查询可以走缓存 一些海里的数据统计分析缓存也做不了 这时候我们还得用到分布式搜索功能 数据库将来主要职责是数据的写操作还有些事务类型 安全性要求较高的数据存储

最后在微服务