说明：
（1）微服务所用技术栈，梳理；
目录
一：微服务技术栈，关系梳理；
（1）微服务技术≠Spring Cloud；
（2）对于一些大型的项目，需要拆分；
（3）微服务：根据业务功能模块，把单体项目拆分成很多独立的项目；
（4）所以，在微服务中，会有一个【注册中心】；
（5）所以，在微服务中，会有一个【配置中心】；
（6）所以，在微服务中，会有一个【服务网关】；
（7）所以，在微服务中，会有一个【分布式缓存】；
（8）所以，在微服务中，会有一个【分布式搜索】；
（9）所以，在微服务中，会有一个【消息队列】；
（10）所以，在微服务中，会有【分布式日志】组件和【系统监控和链路追踪】组件；
（11）所以，微服务需要借助【持续集成】（包括【Jenkins】工具、docker、kubernetes等）；
一：微服务技术栈，关系梳理；
（1）微服务技术≠Spring Cloud；
● 微服务，是分布式架构的一种；分布式架构主要目的是，把服务作拆分；而在拆分的过程中，会产生各种各样的问题；
● 而Spring Cloud仅仅是解决了，服务拆分时的服务治理问题；拆分时的很多其他问题，Spring Cloud并不能解决；
● 所以，一个完整的微服务技术，要包含的不仅仅是Spring Cloud；
（2）对于一些大型的项目，需要拆分；
● 微服务要做的第一件事情就是拆分；因为，传统的单体架构，所有的业务功能都写在一起；随着业务越来越复杂，代码耦合也会越来越严重；那么，将来想要升级维护，就会比较困难；
● 所以，一些大型互联网项目，都会对业务进行拆分；
（3）微服务：根据业务功能模块，把单体项目拆分成很多独立的项目；
● 微服务在拆分的时候，会根据业务功能模块，把单体项目拆分成很多独立的项目，每个项目完成一部分业务功能，同时每个项目独立开发和部署；那么，每个独立的项目都称之为一个服务；
● 一个大型的互联网项目，往往会包含数百甚至上千的服务；最终形成一个服务集群；
● 而，一个需求往往需要多个服务配合，才能完成；
● 那么，当业务越来越多、越来复杂时，服务之间的调用关系也会越来越复杂；如此复杂的调用关系，仅靠人去维护是比较困难的；由此，就引出了【注册中心】；
（4）所以，在微服务中，会有一个【注册中心】；
●【注册中心】会记录微服务中，每一个服务的ip、端口、功能；
● 当某个服务需要调用其他服务时，这个服务不需要自己记住另一个服务的ip，只需要去找【注册中心】就行了，从【注册中心】拉去另一个服务的信息；
● 此外，每个服务都有自己的配置文件；随着服务越来越多，那么当想要修改配置的时候，如果我们手动去逐一修改，会很麻烦；所以，就引出了【配置中心】；
（5）所以，在微服务中，会有一个【配置中心】；
● 【配置中心】可以统一管理服务的配置；
● 如果我们有个配置需要变更，只需要找到【配置中心】即可；【配置中心】会通知相关的服务，实现配置的热更新；
● 当微服务项目运行起来后，用户就可以来访问了；因此，就引出了【服务网关】；
（6）所以，在微服务中，会有一个【服务网关】；
● 因为，我们微服务集群中有很多的服务；那么当用户请求过来的时候，究竟应该首先访问哪个服务呐？而且，要想访问我们的服务，还需要有相应的权限；
● 服务网关，可以校验用户身份；同时，其可以把用户的请求，路由到对应的具体服务上；（当然，在路由过程中，可以做一些负载均衡；而负载均衡的方案就有：Ribbon负载均衡和Nginx的负载均衡）
● 然后，请求进来后，服务处理业务的时候，就可能会访问数据库（PS：大型项目中，数据库会是集群），把对应的数据返回给用户；
● 但是，数据库集群再庞大，肯定没有用户的规模庞大；所以，单靠数据库，是无法抗住高并发的；由此，就引入了【缓存】，而且为了能应对高并发，还得是【分布式缓存】；
（7）所以，在微服务中，会有一个【分布式缓存】；
●【缓存】就是把数据库的数据放在内存中；内存的效率比数据库的硬件高很多；
● 而且，为了应对高并发，还需要【分布式缓存】；
● 用户请求过来的时候，如果需要查询数据，其就会先去缓存中查，缓存未命中再去查数据库；
● 以后，在项目中，还会遇到很多设计复杂搜索的业务；简单查询可以走缓存，一些海量数据的复杂的搜索统计和分析，缓存是做不了的；由此，就引出了【分布式搜索】；
（8）所以，在微服务中，会有一个【分布式搜索】；
● 在实际的分布式项目中，实际上数据库的主要职责，就会是数据的写操作，以及一些涉及数据库事务、对数据安全要求较高的数据存储；
● 而ElasticSearch，就是一个比较常见的分布式搜索引擎；
● 然后，在微服务中，还需要一个异步通信的【消息队列】组件；
（9）所以，在微服务中，会有一个【消息队列】；
● 在微服务（也就是分布式服务啦）中，其同一个需求来了后，为了完整这个需求，往往会跨越多个服务；比如，一个请求来了后，会先调A服务，然后A服务再去调B服务，然后B服务再去调C服务；那么整个业务的链路就会很长，那么调用时长就会是这么多服务执行的时长之和；其实，这样一看，服务的性能是不高的；
● 而，异步通信，就可以改善；
● 异步通信的情况是：一个请求来了后，起还是会先调A服务，A服务不再是调用服务B和C服务了，而是通知B服务和C服务，发一条消息通知B和C去工作，而A服务直接就结束了；这样一看，其业务链路就变短了，响应时间也缩短了；那么整个项目的吞吐能力也变强了；
● 即，【消息队列】这个异步通信的组件，可以大大提高服务的并发；在一些秒杀等高并发场景下，就可以使用；
● 而RabbitMQ和Kafka就是比较常见的消息队列组件；
● 面对如此庞大和复杂的服务，在运行时，如果出现了问题，是比较难排查的；所以，就引出了【分布式日志】组件和【系统监控和链路追踪】组件；
（10）所以，在微服务中，会有【分布式日志】组件和【系统监控和链路追踪】组件；
●【分布式日志】组件，可以统计整个集群中的服务的日志；统一的做一个存储、统计、分析；
●【系统监控和链路追踪】组件，可以实时监控整个集群中每一个服务节点的运行状态、CPU的负载、内存的占用等；一旦出现了问题，能直接定位到具体的方法栈信息；那么，我们就能够快速的定位到问题所在；
● 对于单体应用的部署，我们已经掌握；但是，对于如此庞大复杂的微服务集群，将来很可能有成百上千甚至上万个服务，那么对于如此多的服务，应该怎么更高效的部署呐；由此，就引出了【持续集成】（包括【Jenkins】工具、docker、kubernetes等）；
（11）所以，微服务需要借助【持续集成】（包括【Jenkins】工具、docker、kubernetes等）；
●【Jenkins】工具，可以自动化编译这些微服务项目；基于docker进行打包，形成镜像；然后，基于kubernetes或者RANCHER技术，去实现自动化的部署；
● 结合微服务的技术，然后再借助于【持续集成】的帮助；那么，这才是完整的微服务技术栈；
