1、微服务简介简而言之,微服务架构风格是一种将单个应用程序开发为“一套小型服务”的方法,每个服务“运行在自己的进程中”,并通过轻量级机制(通常是HTTP资源API)进行通信。这些服务“围绕业务功能构建”,并通过全自动部署机制“独立部署”。“这些服务只有最低限度的集中管理”,可能是用不同的编程语言编写的,并使用不同的数据存储技术。 微服务是一种架构,这种架构是将单个的整体应用程序分割成更小的项目关联的独立的服务。一个服务通常实现一组独立的特性或功能,包含自己的业务逻辑和适配器。各个微服务之间的关联通过暴露api来实现。这些独立的微服务不需要部署在同一个虚拟机,同一个系统和同一个应用服务器中。 2、为什么是微服务2.1、单体应用系统一个系统业务量很小的时候所有的代码都放在一个项目中就好了,然后这个项目部署在一台服务器上就好了。整个项目所有的服务都由这台服务器提供。这就是单机结构。 应用随着时间的推进,加入的功能越来越多,最终会变得巨大,一个项目中很有可能数百万行的代码,互相之间繁琐的jar包。 2.2、分布式应用系统由于整个系统运行需要使用到Tomcat和MySQL,单台服务器处理的能力有限,2G的内存需要分配给Tomcat和MySQL使用,随着业务越来越复杂,请求越来越多.。内存越来越不够用了,所以这时候我们就需要进行分布式的部署。 我们进行一个评论的请求,这个请求是需要依赖分布在两台不同的服务器的组件[Tomat和MySQL],才能完成的.。所以叫做分布式的系统。 2.3、集群在上面的图解中其实是存在问题的,比如Tomcat存在单点故障问题,一旦Tomcat所在的服务器宕机不可用了,我们就无法提供服务了,所以针对单点故障问题,我们会使用集群来解决.那什么是集群模式呢 单机处理到达瓶颈的时候,你就把单机复制几份,这样就构成了一个“集群”。集群中每台服务器就叫做这个集群的一个“节点”,所有节点构成了一个集群。每个节点都提供相同的服务,那么这样系统的处理能力就相当于提升了好几倍(有几个节点就相当于提升了这么多倍)。 但问题是用户的请求究竟由哪个节点来处理呢?最好能够让此时此刻负载较小的节点来处理,这样使得每个节点的压力都比较平均。要实现这个功能,就需要在所有节点之前增加一个“调度者”的角色,用户的所有请求都先交给它,然后它根据当前所有节点的负载情况,决定将这个请求交给哪个节点处理。这个“调度者”有个牛逼了名字——负载均衡服务器(Nginx)。 3、系统架构的演变架构的演变大致为:单一应用架构 ===> 垂直应用架构 ===> 分布式服务架构 ===> 流动计算架构微服务架构 ===> [未知] 3.1、单一应用架构互联网早期,一般的网站应用流量较小,只需一个应用,将所有功能代码都部署在一起就可以,这样可以减少开发、部署和维护的成本。 比如说一个电商系统,里面会包含很多用户管理,商品管理,订单管理,物流管理等等很多模块, 我们会把它们做成一个web项目,然后部署到一台tomcat服务器上。 项目架构简单,小型项目的话, 开发成本低。 全部功能集成在一个工程中,对于大型项目来讲不易开发和维护。 3.2、垂直应用架构随着访问量的逐渐增大,单一应用只能依靠增加节点来应对,但是这时候会发现并不是所有的模块都会有比较大的访问量. 还是以上面的电商为例子, 用户访问量的增加可能影响的只是用户和订单模块, 但是对消息模块的影响就比较小. 那么此时我们希望只多增加几个订单模块, 而不增加消息模块. 此时单体应用就做不到了, 垂直应用就应运而生了. 所谓的垂直应用架构,就是将原来的一个应用拆成互不相干的几个应用,以提升效率。比如我们可以将上面电商的单体应用拆分成: 电商系统(用户管理 商品管理 订单管理) 系统拆分实现了流量分担,解决了并发问题,而且可以针对不同模块进行优化和水平扩展。 系统之间相互独立, 无法进行相互调用。 3.3、分布式架构当垂直应用越来越多,重复的业务代码就会越来越多。这时候,我们就思考可不可以将重复的代码抽取出来,做成统一的业务层作为独立的服务,然后由前端控制层调用不同的业务层服务呢? 这就产生了新的分布式系统架构。它将把工程拆分成表现层和服务层两个部分,服务层中包含业务逻辑。表现层只需要处理和页面的交互,业务逻辑都是调用服务层的服务来实现。 抽取公共的功能为服务层,提高代码复用性。 系统间耦合度变高,调用关系错综复杂,难以维护。 3.4、SOA架构在分布式架构下,当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需增加一个调度中心对集群进行实时管理。此时,用于资源调度和治理中心(SOA Service Oriented Architecture,面向服务的架构)是关键。 使用注册中心解决了服务间调用关系的自动调节 服务间会有依赖关系,一旦某个环节出错会影响较大( 服务雪崩 )。 注册中心: nacos ,zookeeper ,nacos ,eureka,consul 3.5、微服务架构微服务架构在某种程度上是面向服务的架构,它更加强调服务的"彻底拆分"。 服务原子化拆分,独立打包、部署和升级,保证每个微服务清晰的任务划分,利于扩展。 分布式系统开发的技术成本高(容错、分布式事务等)。 4、微服务需要解决的问题微服务架构, 简单的说就是将单体应用进一步拆分,拆分成更小的服务,每个服务都是一个可以独立运行的项目。 微服务架构的常见问题 这么多小服务,如何管理他们? 5、微服务架构的常见概念5.1、服务治理服务治理就是进行服务的自动化管理,其核心是服务的注册与发现。 服务注册:服务实例将自身服务信息注册到注册中心。 5.2、服务调用在微服务架构中,通常存在多个服务之间的远程调用的需求,目前1主流的远程调用的技术有基于HTTP请求的RESTFul接口及基于TCP的RPC协议。 REST(Representational State Transfer):这是一种HTTP调用的格式,更标准,更通用,无论哪种语言都支持http协议。
5.3、服务网关随着微服务的不断增多,不同的微服务一般会有不同的网络地址,而外部客户端可能需要调用多个服务的接口才能完成一个业务需求,如果让客户端直接与各个微服务通信可能出现: 客户端需要调用不同的url地址,增加难度。 API网关直面意思是将所有API调用统一接入到API网关层,由网关层统一接入和输出。一个网关的基本功能有:统一接入、安全防护、协议适配、流量管控、长短链接支持、容错能力。有了网关之后,各个API服务提供团队可以专注于自己的的业务逻辑处理,而API网关更专注于安全、流量、路由等问题。 5.4、服务容错在微服务当中,一个请求经常会涉及到调用几个服务,如果其中某个服务不可用,没有做服务容错的话,极有可能会造成一连串的服务不可用,这就是雪崩效应。 我们没法预防雪崩效应的发生,只能尽可能去做好容错。服务容错的三个核心思想是: 不被外界环境影响。 5.5、链路追踪随着微服务架构的流行,服务按照不同的维度进行拆分,一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上,这些软件模块,有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器,横跨多个不同的数据中心。因此,就需要对一次请求涉及的多个服务链路进行日志记录,性能监控即链路追踪。 6、微服务常见的解决方案6.1、ServiceComb官网地址: https://servicecomb./cn/ 6.2、SpringCloud官网地址: https://www./ (中文) Spring Cloud并没有重复制造轮子,它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理,最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。 6.3、Spring Cloud Alibaba官网地址: ttps:///projects/spring-cloud-alibaba 6.4、Dubbo+ZookeeperDubbo官网地址: https://dubbo./zh/ Dubbo+Zookeeper 一、Dubbo是什么?
|
|
来自: ZhouAndrew > 《Java》