【微服务技术01】微服务技术栈--模块组成

【微服务技术01】微服务技术栈–模块组成

微服务是分布式架构的一种，分布式架构就是要把服务做拆分，而拆分的过程中会产生各种问题，而SpringCloud只是解决了服务拆分过程中的服务治理问题，其他的一些服务拆分更复杂问题没有给出完整的解决方案，所以一个完整的微服务技术要包含的不仅仅是SpringCloud。

服务集群

传统单体架构，所以业务都写在一起，代码耦合性越来越高，所以一些大型互联网项目要做拆分，微服务做拆分时会根据业务功能模块把一个单体的项目拆分成许多独立的项目，每个项目完成一部分业务功能，将来独立开发和部署，独立出来的项目称为一个服务，一个大型的互联网项目可能包含成百上千个服务，最终形成一个服务集群，而一个业务往往需要多个服务共同来完成，比如服务A调用服务B，服务B又调用服务C…当业务越来越复杂时，它们之间的调用关系就会更复杂，难以记录维护。

注册中心

于是注册中心应运而生，它可以记录微服务中每一个服务的ip端口和功能，当一个服务A需要调用服务B时，不需要知道服务B的ip和端口，只需要向注册中心拉取或注册服务信息。

配置中心

但如果要更改服务的配置信息，一个个去修改就太麻烦了，所以微服务中还要有一个配置中心，它可以统一的管理整个服务集群中成百上千的配置，如果某个服务的配置信息需要变更，只需要去找配置中心即可，配置中心会通知相关微服务实现配置的热更新。

服务网关

服务集群中有众多服务，用户要如何知道访问哪个，而且不是所有服务都有权限访问，服务网关可以对用户身份做校验，另外把我们的请求路由到具体的某个服务，当然在路由过程中就可以做一些负载均衡，服务收到请求就可以做访问数据库的操作返回数据。

分布式缓存

当数据量很多或者对访问速度要求高时，就需要引入分布式缓存，而且为了应对高并发，分布式缓存也是一个集群，如果缓存未命中再去查询数据库。

分布式搜索

对于简单的查询分布式缓存就可以完成功能，但是复杂的查询就可能要用到分布式搜索，数据库之后的作用主要是一些写操作和一些事物类型的多数据安全性较高的存储。

消息队列

最后，微服务中还需要一些异步通信多消息队列组件，因为对于微服务中的业务往往需要跨越多个服务，一个请求服务A调用服务B，服务B调用服务C，整个业务的链路很长，调用时长就等于每个服务调用之和，性能下降。而异步通信的的意思是业务来了不是服务A调用服务B，而是服务A去通知需要的服务比如B、C去干活，而服务A就直接结束了，缩短服务链路，提高吞吐能力。因此异步通信可以大大提高服务的并发能力，比如适应一些秒杀场景。

分布式日志服务

对于以上如此庞大的服务，如果某个环节出了问题不好排查，于是需要引入分布式日志服务，统计整个集群中成百上千个服务的日志做统一的存储管理与分析。

系统监控链路追踪

系统监控链路追踪可以实时监控整个集群中每一个服务节点的运行状态，CPU的负载，内存占用等等，一旦出现任何问题可以定位到某个具体的方法栈信息，快速定位到异常所在。

持续集成

如此庞大成千上百的服务集群，一个个去部署实在是太麻烦了，可以利用比如Jenkins自动化部署工具对整个微服务项目进行自动化的编译，基于docker做一些打包形成镜像，再基于Kubernetes或者RANCHER等技术实现自动化等部署，这一整套自动化部署管理可以称为持续集成。结合以上微服务这些技术再加上持续集成，形成一套完整的微服务技术栈。

技术栈