微服务技术栈

        微服务在做单体架构拆分时，会根据业务功能模块把一个单体的项目拆分成很多个独立的项目，每一个项目负责一部分业务功能，将来独立开发和部署，我们把一个个独立的项目称为一个个服务，在企业中，一个大型的项目可能包含数百甚至上千个服务，最终形成一个服务集群：

        而一个业务往往需要多个服务来完成，比如一个请求来了，可能先去调用服务A，然后又去调用服务B，服务B又去调用了服务C ；当业务越来越多，越来越复杂的时候，这些服务之间的调用关系就会越来越复杂，这么复杂的业务关系想靠人去记录和维护是不可能的，所以在微服务里，就会有一个组件，叫做注册中心，它可以去记录微服务中每一个服务的ip,端口，以及它能干什么事情这些信息：

同时，每一个服务都有一个配置文件，将来要更改配置，逐一更改会很麻烦，所以在微服务里还会有一个配置中心，它可以去统一的管理整个服务集群中成百上千个配置 ，当以后一些配置要变更，只需要去找到配置中心就可以了，它会去通知微服务实现配置的热更新：

当微服务运行起来过后，用户就可以来访问我们，这时就需要一个网关组件 ，服务网关一方面是对用户身份进行校验，另一方面可以把用户的请求路由到对应的服务：

         然后服务会去操作对应的数据库，这里画的是一个数据库，但是数据库一般是集群，虽然数据库是集群，但是集群再庞大，肯定没有用户多吧，用户会发送大量的请求，，为了抗住请求高并发，就需要有分布式缓存（将数据库数据放入到内存当中，内存的查询效率比数据库要高很多）

我们业务中，还会有很多复杂的搜索功能，还需要用到分布式搜索功能 ：

最后，在微服务中，还需要一个异步通讯的消息队列组件，为什么呢？其实对于分布式的微服务来说，一个请求往往会跨越多个服务，比如，一个请求来了，先调用A，A再调用B，B再调用C，整个业务的链路就很场，链路时长就会等于每一个服务的执行时长之和，其实这样性能是有一定的下降的，而异步通讯的意思就是，请求来了，调用A，A不再是去调用B和C，而是发个消息通知B和C，此时服务A就直接结束了，这样链路变短了，服务时间也变短了，吞吐能力也变强了，所以异步通讯可以大大提高服务的并发：

 

当然，我们如此庞大的复杂业务服务，在运行的过程中，如果出现什么问题了，需要排查，因此我们还需要引入①分布式日志服务 ，它可以去统计整个集群中成百上千的服务的运行日志，统一的存储、分析，将来出现二体就比较好分析了②系统监控链路和追踪，它可以去实时监控整个服务集群中每个服务节点的运行状态，CPU负载，内存占用情况等，一旦出现任何的问题，直接可以定位到具体的服务：

那么如此庞大，复杂的一个微服务集群，部署怎么办呢？如果还是靠以前人工去部署现实吗？不现实！所以还需要去做自动还部署，我们可以利用Jenkins,它可以对这些微服务进行自动化的编译，基于docker它可以去做一些打包，形成镜像，再基于，kubernetes和rancher进行自动化的部署，自动部署的整个过程我们称之为持续集成

加上微服务的整个架构再加上持续继承，这样才叫做整个微服务的技术栈