初识微服务技术栈

认识微服务

随着互联网行业的发展，对服务的要求也越来越高，服务架构也从单体架构逐渐演变为现在流行的微服务架构，这些架构之间有怎样的差别呢？

导学：

了解微服务的优缺点；
了解微服务架构的演变过程；
认识微服务的一种实现：Spring Cloud

微服务架构的演变

单体架构

单体架构：将业务的所有功能都集中在一个项目中开发，打成一个包去部署。

单体架构的优缺点如下：

优点：

架构简单
部署成本低

缺点：

耦合度高，扩展性差，因为所有代码写在一个项目里（维护困难、升级困难），适合小型项目，比如：学生管理系统

分布式架构

分布式架构：根据业务功能对系统做拆分，每个业务功能模块作为独立项目开发，称为一个服务，说白了就是按照业务垂直划分，每个业务都是单体架构，通过API互相调用。

分布式架构的优缺点：

优点：

降低服务耦合
扩展性好，有利于服务升级和拓展

缺点：

难度大，服务调用关系错综复杂（只能远程调用：跨越机器、跨越服务的调用），适合大型互联网项目，比如：淘宝、京东

分布式架构虽然降低了服务耦合，但是服务拆分时也有很多问题需要思考：

服务拆分的粒度如何界定？
服务集群的地址如何维护？
服务之间如何实现远程调用？
服务的调用关系如何管理？
服务健康状态如何感知？万一你这个服务都挂了我还来调你，导致我这里也调用失败 - 级联失败

人们需要指定一套行之有效的标准来约束分布式架构，因此就出现了微服务~！

知识补充：热更新（Hot Reload）

热更新指的是应用程序运行时，修改程序代码后无需重启整个应用程序，而是只需要重新加载修改后的部分代码，使得修改的代码可以立即生效，通过这种方式，可以避免每一次修改后都需要重新启动应用程序，等待整个应用程序重新加载的情况出现，使得开发人员可以更加方便地进行代码调试和修改。

什么是微服务？

微服务是一种经过良好架构设计的分布式架构方案。

微服务的优缺点：

优点：

拆分粒度更小、服务更独立、耦合度更低

缺点：

架构非常复杂，运维、监控、部署难度提高

微服务的架构特征：

单一职责：微服务的拆分粒度更小，每一个服务都对应唯一的业务能力，每个服务都围绕着具体业务进行构建，做到单一职责，避免重复业务开发
面向服务：微服务要对外暴露业务接口（这样服务之间就可以做一些相互的调用了），服务提供统一标准的接口，与语言和技术无关
自治：指的就是独立：团队独立、技术独立、数据独立（是指每个服务可以有自己独立的数据库）、部署独立（能够被独立的部署到生产环境）和交付独立
隔离性强：服务调用要做好隔离、容错、降级，避免出现级联问题

微服务的上述特征其实是在给分布式架构制定一个标准，这些特征其实最终的目的就是为了实现高内聚、低耦合，降低服务之间的耦合度，（降低服务它所能产生影响的范围），提高服务的独立性和灵活性，避免整个集群的故障！

因此，可以认为微服务是一种经过良好架构设计的分布式架构方案。

微服务它一种其实是分布式架构的一种，所谓分布式架构就是要把服务做拆分，而拆分的过程中其实会产生各种各样的问题需要去解决，而Spring Cloud其实仅仅是解决了服务拆分时的服务治理问题，至于其它的一些分布式的更复杂的一些问题，并没有给出解决方案，所以一个完整的微服务技术，要包含的不仅仅是Spring Cloud。

微服务要做的第一件事情就是拆分，因为传统的单体结构，所有的业务功能全部写在一起，随着业务越来越复杂，代码也变得耦合的越来越多，将来你想升级、维护就会很困难，所以像一些大型的互联网项目，就必须去做拆分；
微服务在做拆分的时候，会根据业务功能模块把一个单体的项目拆分成许多个独立的项目，每个项目完成一部分业务功能，将来独立开发和部署，我们把这样一个独立的项目称为一个服务；
一个大型的互联网项目往往会包含数百甚至上千的服务，最终形成一个服务集群，而集群中的每个服务都要遵循单一职责的原则，并且要面向服务，对外暴露业务接口，这样服务之间就可以做一些相互的调用，只不过不同技术在实现这些接口的时候，可能会有差异；
而一个业务往往需要有多个服务共同来完成，比如说一个请求来了，它可能先去调了服务A，而服务A可能又调了服务B，然后又去调了服务C，当业务越来越多，越来越复杂的时候，这些服务之间的调用关系就会越来越复杂，这么复杂的一个调用关系一定需要我们去维护，想靠人去记录和维护，这是不可能的，所以在微服务里，一定会有一个组件，叫做注册中心：它可以去维护微服务里面每个节点的信息，并且去监控这些节点的状态：它可以去记录微服务中每一个服务的IP、端口以及它能干什么事这些信息，当有一个服务需要调用另外的服务时，它不需要自己去记录对方的IP，只需要去找注册中心就行了，由注册中心去拉取对应的服务信息；
并且将来随着服务越来越多，每一个服务都有自己的配置文件，如果将来有一些配置需要去做修改，将来如果要更改配置，难道我们手动的去微服务里面逐一去修改吗？这就太麻烦了，所以在微服务里还会有一个配置中心：它可以去统一的管理整个服务群体成千上百的这个配置信息，如果以后有配置需要变更，只需要去找到配置中心就可以了，它会去通知相关的微服务，利用通知的方式去让对应的服务服务监控到配置的变化，从而实现配置的热更新；
将来当我们的微服务一旦部署上线，用户就可以来访问我们了，但这个时候，还需要有一个网关组件，因为你这里有这么多的微服务，用户怎么知道该访问哪一个呢？而且也不是说你随便什么人都能来访问我们的服务吧，所以这些服务集群还需要有一个统一的服务网关作为入口，我们的服务网关一方面就是对用户身份对校验，另一方面就是由网关把用户的请求路由到我们的具体的服务，当然在路由过程中，也可以去做一些负载均衡，并且路由的时候或者服务之间的调用过程中，我们还要做好服务的容错处理，避免因为服务故障带来级联失败，还要做好服务保护、隔离、降级等等这些措施；
而这时候呢，服务进入到你的请求去处理业务，该访问数据库的时候就去访问数据库，最后再把查询到的数据返回给用户，将来数据库肯定要做集群，但是你集群再庞大，也不可能有用户多把，所以数据库将来肯定无法抗住高并发的场景，因此还会加入缓存，缓存就是把数据库数据放入到内存当中，内存查询效率肯定要比数据库快很多，而且这种缓存还不能是单体缓存，为了应对高并发，还要做成分布式缓存，也是一个集群：用户请求先到缓存，缓存未命中，再去查询数据库。
以后我们的业务中还会有一些复杂的搜索功能，简单查询可以走缓存，一些海量数据的复杂的搜索、统计和分析，缓存也做不了，这个时候就需要用到分布式搜索功能，数据库将来主要的职责其实就是做一种数据的写操作，还有一些事务类型、对数据安全要求较高的一些数据存储；
最后在微服务里边，还需要一种异步通信的消息队列组件，因为对于这种分布式的服务或者微服务里面，它的业务往往会跨越多个服务，一个请求来了，先调的服务A，A再调B，B再去调C，整个业务的链路就很长，调用时长就会等于每个服务的执行时长之和，所以其实性能是有一定的下降的，而异步通信的意思就是，请求来了，我调了服务A，服务A我不是去调你服务B和C，而是通知你们，发一条消息，你们两个赶紧干活去，于是，那两个哥们去干了，而服务A直接结束了，所以它的业务链路就会变短了，响应时间也缩短了，自然吞吐能力也就变强了，所以异步通信可以提高我们服务的并发，在一些类似于秒杀这样的高并发场景下就可以去利用了。

当然，我们如此庞大和复杂的一个服务，在运行的过程当中，如果出现了什么问题，就不太好排查，所以在微服务运行过程中，我们还会引入两个新的组件来去解决服务的异常定位：

第一个是分布式日志服务，它可以去统计整个集群当中成千上百的这些服务，它们的运行日志，统一的去做一个存储、统计和分析，将来如果出现问题，就比较好定位了；
而且还有第二个东西，叫做系统监控和链路追踪，它可以去实时监控我们整个群体中每一个服务节点的一个运行状态、CPU的负载、内存的占用等等的情况，一旦出现任何的问题，直接可以定位到具体的某一个方法（栈信息），那么你就能够很快速的定位到异常所在了。

那么如此庞大、复杂的一个微服务集群，将来很有可能会达到成千上万的服务，这个时候，我们部署该怎么办呢？

如果还是靠以前，人工去部署，显然不太现实，所以将来这些微服务集群还需要去做一种自动化的部署，我们就会利用Jenkins这样的工具，它可以对这些微服务项目进行自动化的编译，基于docker再去一些打包，形成镜像，再基于kubernetes（K8s）或RANCHER这样的技术去实现自动化的部署，这一套我们称之为持续集成。

结合微服务的这些技术再加上持续集成，这才是完整的微服务技术栈！

微服务技术对比

目前最流行的两种微服务解决方案是Spring Cloud和Dubbo。

微服务这种方案也需要技术框架来落地，全球的互联网公司都在积极尝试开发自己的微服务落地技术，在国内最知名的就是Spring Cloud和阿里巴巴的Dubbo => 不管是Spring Cloud还是Alibaba的Dubbo，都是微服务方案的实现，所以它们所包含的组件实现的功能基本是一致的，首先它们都需要去做微服务的拆分，形成微服务集群，而集群中的每个服务都要遵循单一职责的原则，并且要面向服务，对外暴露业务接口，这样服务之间就可以做一些相互的调用了...
微服务这种分布式架构方案的落地，其实在Java领域最引人注目的就是SpringCloud提供的方案了。

Spring Cloud和Dubbo其实它们在实现的过程中，其实是有一些差异的：

Dubbo技术它早在2012年左右就已经开源出来了，是Alibaba公司开源的，但是那个时候微服务技术在国内可能连听都没听过，所以说Dubbo并不是严格意义上的一个微服务技术，在那个时候，它的核心就是服务的远程调用以及注册发现，所以在Dubbo里面技术体系并不完整，而且注册中心也不是Dubbo里面自己实现的，而是依赖于zookeeper、Redis去做的，这些并不是专业的注册中心（半吊子），像Redis是做缓存的，zookeeper是做集群管理的，所以Dubbo并不具备完善的注册中心功能，而服务的这种远程调用才是Dubbo的核心，在当时，Dubbo专门基于这种TCP的协议定义了一套标准，也就是Dubbo协议，所以遵循Dubbo这种远程调用，必须得定义Dubbo这种标准的接口。而且配置中心和服务网关Dubbo都没有实现，至于服务监控Dubbo里面只提供了一个非常基本的dubbo-admin功能，只是来统计一下服务调用时的一个响应时间、QPS等等，功能非常单一，所以Dubbo所实现的这个服务的治理，其实是非常不完善的。

而到了2015年~2017年这段时间，可以说是微服务技术井喷的时候，各种各样的微服务技术层出不穷，但是一直没有一个一统江湖的，直到Spring Cloud的出现，Spring Cloud它并不是发明了什么东西，而是整合，它把全球各个公司的开源的这种微服务技术都给整合起来了，而后形成了一套完整的微服务技术体系，是一个集大成者，它里面的功能是非常完善的，它首先有完善的注册中心，里面包含了Eureka、Consul这种专业的注册中心，并且Spring Cloud的服务调用它并没有去整一种全新的协议和标准，它用的是直接基于HTTP协议的标准的Feign客户端，由它来去发送HTTP的请求（不用它也行，只要遵循Restful风格 => 基于HTTP协议的RESTful API），Spring Cloud还提供了专业的配置中心，叫做SpringCloudConfig，另外Spring Cloud还提供了SpringCloudGetway以及Zuul两个不同的网关，在目前比较流行的是SpringCloudGetway网关，因为它里面基于了最新的响应式编程，吞吐能力非常强，还有服务监控和保护 - Hystrix，Hystrix它是一个非常强大的服务保护技术，但是它里面也带有一些监控的功能，但核心是保护，主要就是实现了服务的隔离和熔断等等一些相关技术，功能也是十分强大。

由于Dubbo和Spring Cloud相比还是存在比较大的差距，Dubbo它不是一个完善的微服务的技术栈，所以阿里巴巴也认识到了这一点，因此阿里巴巴为了追赶Spring Cloud的脚步，形成了一套能够与Spring Cloud无缝衔接的开源组件和工具，也就是Spring Cloud Alibaba，Spring Cloud Alibaba本质上是实现了Spring Cloud标准的，所以可以认为Spring Cloud Alibaba是Spring Cloud的一部分，Spring Cloud Alibaba是Spring Cloud的拓展，用于构建云原生微服务应用。

Spring Cloud和Spring Cloud Alibaba在概念和功能上有很大的相似性，都致力于构建和管理微服务架构，但Spring Cloud Alibaba更加专注于阿里巴巴云生态，并提供了一些额外的功能和针对云原生应用的支持。