论文部分内容阅读
摘要：随着互联网的发展，需求的多样化，应用的规模越来越大，人们要求能实现更多的功能和更多服务。该文介绍了微服务的发展现状、应用前景。
关键词：单体式架构;分布式;微服务;spring Cloud;Dubbo
中图分类号：G642 文献标识码：A
文章编号：1009-3044（2020）14-01 17-01
1微服务出现的原因
早期的应用都部署到一台服务器上，随着访问量的逐渐增加，为了增大应用的吞吐量，就有了采用多个服务器部署一个应用的方式，即分布式服务。不过这仍然是单体式架构，随着应用体量越来越大，耦合的问题逐渐凸显出来了。这个时候不仅需要一种新的架构能应对与日俱增的访问量，还需要把大型应用的开发和维护变的更加明确清晰，于是微服务就应运而生。
2微服务
微服务可以视为分布式的一种实现，具体则是把一个单体应用按照实际需求划分出多个部分，每个部分都只负责完成一部分功能支持服务。但这些微服务之间彼此关联又界限清晰，有需要的时候就可以相互调用。
2.1微服务优点
每一个微服务都可以视为一个应用，能够独立部署，可以根据业务需要对微服务进行增减或者改变。甚至一个微服务对应一种编程语言，这是一项很大的优势，极大增加了开发的自由度，让不同公司和团队也能从低门槛参与一个项目中。
2.2微服务缺点
如何有效做到监控不同服务器中的服务，这是微服务的难点之一。由于使用了分布式的技术，微服务难免会有出现和分布式类似的问题。例如，如何保证微服务之间的通信正常、数据库的一致性等。
3微服务与Spring Cloud
3.1方便的Spring Cloud框架
SpringCloud和springBoot关系密切，也同样具备了配置默认和整合其他框架的特点。除此之外还得益于Privotal的技术支持和Netflix的开源，SpringCloud不仅有可靠的技术作为支撑，而且还自带一整套常用的微服务组件。
3.2框架下的组件
常用的组件包括用于自动、动态、统一管理分布式系统的Config，用于熔断、降级的熔断器Hystrix，与Hystrix配套使用、监控整个微服务系统的数据和流量的Turbine，实现动态路由的Zuul，实现微服务的自动化注册和发现的Eureka，监视Eure-ka Server并且实现负载均衡的Ribbon。其他的还有实现微服务互相调用的Feign、消息总线的Bus和服务跟踪的Sleuth等。
3.3基础架构关系
3.3.1微服务与客户端
微服务系统内部是通过RPC来实现相互调用，在客户端和服务端则是通过基于HTTP的REST方式发送请求来实现信息交流。客户端的请求全都需要经过OAuth2认证以区分所有的请求是来自客户端还是服务端，所以OAuth2就配置在Zuul中，并且在Zuul内还会通过Ribbon实现负载均衡。整个系统都会被Zuul包围，用户如果想发送请求调用到其中的微服务，则请求必须经过Zuul的认证。
3.3.2微服务的管理、使用和维护
为了便于开发和维护，所有的微服务都必须会被统一管理，并且包括网关和新添加的服务都会被注册到Eureka。Eure-ka中有注册、更新服务的配置信息，还有关于整个服务系统的配置信息（可以从Git下载）例如版本号等，会由Config一起配置到服务器当中。运行过程中，熔断器Hystrix搭配Turbine一起使用，我们可以通过Turbine提供的图形界面随时获取各处流量负载的信息。
3.4對负载量过高的处理
Ribbon可以能够应对一定限度的高并发问题。如果访问量不停增加，出现负载过重，可以利用Hystrix对相应部分的微服务进行熔断。
4中国微服务架构使用现状
4.1Dubbo
Dubbo是阿里巴巴公司开发的开源微服务框架。尽管Dubbo只实现了微服务中的服务化治理，但由于阿里在国内互联网的影响力较大以及中文文档较为完善，开源组件也在国内其他互联网公司中应用，因此Dubbo目前是国内微服务的主流框架。
4.2相较之下Spring Cloud的前景
两项技术各有特点，Dubbo在国内的使用更加成熟，不过由于自带的非微服务组件较多，如protocol、register、DubboSPI还有整合各种微服务组件的Dubbo Filter等，上手难度较大，而且维护更新频率较低。而Spring Cloud提供一整套完整的微服务，不仅发展迅速而且持续得到维护更新，更重要的是使用统一的框架技术更符合持续集成、快速交付这一重要理念。尽管现在Spring Cloud不如Dubbo知名度高，但是以后的使用量应该会逐步上升。
5适合使用微服务的场景
是否适合使用微服务主要看哪些是不是体量大、访问量大的应用，同时也看应用本身的业务逻辑是否清晰，服务之间是否有明确的界限。
6微服务的意义
随着电子化、信息化飞速发展，传统的架构都已经出部分不足之处。如应用划分边界模糊、应用开发分工不明确、高并发问题等。为了更好地避免这些问题，微服务的应用越来越火了。
关键词：单体式架构;分布式;微服务;spring Cloud;Dubbo
中图分类号：G642 文献标识码：A
文章编号：1009-3044（2020）14-01 17-01
1微服务出现的原因
早期的应用都部署到一台服务器上，随着访问量的逐渐增加，为了增大应用的吞吐量，就有了采用多个服务器部署一个应用的方式，即分布式服务。不过这仍然是单体式架构，随着应用体量越来越大，耦合的问题逐渐凸显出来了。这个时候不仅需要一种新的架构能应对与日俱增的访问量，还需要把大型应用的开发和维护变的更加明确清晰，于是微服务就应运而生。
2微服务
微服务可以视为分布式的一种实现，具体则是把一个单体应用按照实际需求划分出多个部分，每个部分都只负责完成一部分功能支持服务。但这些微服务之间彼此关联又界限清晰，有需要的时候就可以相互调用。
2.1微服务优点
每一个微服务都可以视为一个应用，能够独立部署，可以根据业务需要对微服务进行增减或者改变。甚至一个微服务对应一种编程语言，这是一项很大的优势，极大增加了开发的自由度，让不同公司和团队也能从低门槛参与一个项目中。
2.2微服务缺点
如何有效做到监控不同服务器中的服务，这是微服务的难点之一。由于使用了分布式的技术，微服务难免会有出现和分布式类似的问题。例如，如何保证微服务之间的通信正常、数据库的一致性等。
3微服务与Spring Cloud
3.1方便的Spring Cloud框架
SpringCloud和springBoot关系密切，也同样具备了配置默认和整合其他框架的特点。除此之外还得益于Privotal的技术支持和Netflix的开源，SpringCloud不仅有可靠的技术作为支撑，而且还自带一整套常用的微服务组件。
3.2框架下的组件
常用的组件包括用于自动、动态、统一管理分布式系统的Config，用于熔断、降级的熔断器Hystrix，与Hystrix配套使用、监控整个微服务系统的数据和流量的Turbine，实现动态路由的Zuul，实现微服务的自动化注册和发现的Eureka，监视Eure-ka Server并且实现负载均衡的Ribbon。其他的还有实现微服务互相调用的Feign、消息总线的Bus和服务跟踪的Sleuth等。
3.3基础架构关系
3.3.1微服务与客户端
微服务系统内部是通过RPC来实现相互调用，在客户端和服务端则是通过基于HTTP的REST方式发送请求来实现信息交流。客户端的请求全都需要经过OAuth2认证以区分所有的请求是来自客户端还是服务端，所以OAuth2就配置在Zuul中，并且在Zuul内还会通过Ribbon实现负载均衡。整个系统都会被Zuul包围，用户如果想发送请求调用到其中的微服务，则请求必须经过Zuul的认证。
3.3.2微服务的管理、使用和维护
为了便于开发和维护，所有的微服务都必须会被统一管理，并且包括网关和新添加的服务都会被注册到Eureka。Eure-ka中有注册、更新服务的配置信息，还有关于整个服务系统的配置信息（可以从Git下载）例如版本号等，会由Config一起配置到服务器当中。运行过程中，熔断器Hystrix搭配Turbine一起使用，我们可以通过Turbine提供的图形界面随时获取各处流量负载的信息。
3.4對负载量过高的处理
Ribbon可以能够应对一定限度的高并发问题。如果访问量不停增加，出现负载过重，可以利用Hystrix对相应部分的微服务进行熔断。
4中国微服务架构使用现状
4.1Dubbo
Dubbo是阿里巴巴公司开发的开源微服务框架。尽管Dubbo只实现了微服务中的服务化治理，但由于阿里在国内互联网的影响力较大以及中文文档较为完善，开源组件也在国内其他互联网公司中应用，因此Dubbo目前是国内微服务的主流框架。
4.2相较之下Spring Cloud的前景
两项技术各有特点，Dubbo在国内的使用更加成熟，不过由于自带的非微服务组件较多，如protocol、register、DubboSPI还有整合各种微服务组件的Dubbo Filter等，上手难度较大，而且维护更新频率较低。而Spring Cloud提供一整套完整的微服务，不仅发展迅速而且持续得到维护更新，更重要的是使用统一的框架技术更符合持续集成、快速交付这一重要理念。尽管现在Spring Cloud不如Dubbo知名度高，但是以后的使用量应该会逐步上升。
5适合使用微服务的场景
是否适合使用微服务主要看哪些是不是体量大、访问量大的应用，同时也看应用本身的业务逻辑是否清晰，服务之间是否有明确的界限。
6微服务的意义
随着电子化、信息化飞速发展，传统的架构都已经出部分不足之处。如应用划分边界模糊、应用开发分工不明确、高并发问题等。为了更好地避免这些问题，微服务的应用越来越火了。