关注下一代微服务： Server Mesh
代表解决方案：istio
微服务技术栈
【SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式，系统详解springcloud微服务技术栈课程|黑马程序员Java微服务】
什么是微服务
微服务就是SpringCloud 吗？【答案是否定的】
微服务其实分布式架构的一种，所谓分布式架构就是要对服务进行拆分
而拆分的过程中，会产生各种各样的问题需要解决，那SpringCloud 仅仅是解决了服务拆分时的服务治理问题，即其他的一些分布式的一些更复杂的问题并没有给出解决方案
所以！一个完整的微服务技术，它要包含的东西不仅仅是SpringCloud
【所以到底有哪些技术呢？】
1.1.2 微服务技术栈
微服务要做的第一件事情就是拆分。
单体架构：将业务的所有功能集中在一个项目中开发，打成一个包部署。
这种模式随着业务越来越复杂， 代码越来越多【将来想要升级维护就会很困难】
【所以在一些大型的互联网项目中，都要做拆分】
微服务在做拆分的时候，
会将一个单体的项目，拆分成许多个独立的项目，每个项目完成独立的业务功能，我们把这样一个独立的项目称为一个服务
所以大型项目中，很多可能就会包含几百、上千的服务，最终形成一个服务集群
而一个业务往往又需要多个服务共同来完成，当服务越来越多，服务间的调用关系就会越来越复杂
这么复杂的一个关系，如果靠人去记录维护，【不可能】
所以微服务组件——注册中心就来了
它可以记录服务集群中每一个服务的一系列信息
当有一个服务需要调用另外的服务时，它不需要自己去记录对方的ip 等信息，只需要去找注册中心就行了
从注册中心拉取对应的服务信息。
同时，随着服务越来越多，每个服务都有自己的配置文件，将来如果要更改，人工…可想而知
所谓微服务组件——配置中心来了
它可以统一管理整个服务集群里的所有配置
如果有服务的配置需要变更，就去找配置中心就行了，它会通知相关的微服务，实现“热更新”
当微服务运行起来之后，用户需要访问，这个时候微服务组件——服务网关，因为微服务多了，用户不知道应该访问哪一个，而且也不是说随便什么人都能访问我们的微服务，【服务网关一方面方便对访问用户身份做校验，另一方面可以把用户的请求路由到具体的服务】
当然在这个过程中，也可以去做一个负载均衡
接下来的事儿，就是服务去处理业务，该访问数据库就去访问数据库，最终把查到的数据返回给用户就OK了
所以这个时候又有了新的问题，数据库集群再庞大，也超不过用户啊
所以数据库很难扛住高的并发，因此我们还会加入一个组件——缓存
用户请求先走缓存，缓存未命中，再去查询数据库
而且以后的业务中，还会有一些复杂的搜索功能，简单数据可以做缓存，一些海量的数据搜索分析，缓存就不能做了，这个时候就要加入 分布式搜索功能，所以在将来数据库的任务就是做一些写操作，和一些事务类型的操作以及一些对数据安全性要求较高的存储
最后在微服务中还需要一个进行异步通信的消息队列组件
因为对于分布式的服务，它的一个业务往往会划分为多个服务，一个请求来了，先调了服务A，A再调B，B再调C
这个业务的链路就很长，如果是同步的话，就会导致业务时长 = 每个服务的执行时长之和，这样也会影响性能
而异步，就不会说是等谁了，而是以一种通知的形式，告诉哪些服务要干活儿了
这样吞吐能力也就变强了
所以异步通信可以大大提高服务的并发【秒杀、高并发】
新的问题，如果整个微服务，运行过程出现了异常，这么庞大的系统，会不好排查，所以还有两个组件
第一个 —— 分布式日志服务，
它可以统计整个集群中，所有服务的运行日志，统一的进行处理
还有一个叫系统监控链路追踪
它可以实时地去监控我们集群中每一个服务的节点的运行状态等等情况，一旦出现问题，可以直接定位
这么庞大一套东西，部署的问题也就随之产生了，
如果人工部署，【不现实】
所以还是要利用自动化部署
利用Jenkins 对集群进行编译，基于Docker 再实现一些打包
再基于K8S或者Rancher 这样的技术实现自动化的部署
这一套东西，我们称之为，持续化集成
到这里，这才是完整的微服务技术栈