技术干货分享:微服务浅谈服务治理的演变过程
本篇文章先简单介绍了互联网架构的演变,进而介绍了服务化,最后介绍了微服务及最新的服务网格(Service Mesh)。 互联网架构演变 一体架构 在计算机软件发展早期,一般桌面软件都是采用这种架构,不管是界面还是业务处理还是数据处理都放到一个包中。这种其实谈不上架构,但也可以说是很好的架构,因为它足够简单。 mvc架构 但随着浏览器的出现便产生了web应用,web应用的特点是界面部分是显示在浏览器中,服务处理是在服务容器中的,页面显示一般用css+js+html技术来处理,而后端可以用java、php等语言,这就产生了前后端分离。对于web系统,一体架构难以满足前后端分离的开发需求,因而便产生了MVC架构。 MVC才算的上真正意义上的架构,因为它除了解决了前后端分离问题,还引入了一种全新的开发模式,用一种业务逻辑、数据、界面显示分离的方法组织代码,使得整个应用层次更加分明,而且各个层次之间不但减低了耦合性,还提高了各个层次的可重用性。 但随着应用规模的不断扩大,应用模块不断增加,整个应用也显得越来越臃肿,维护起来也更加困难,因此便又产生了多应用架构。 多应用架构 多应用架构很简单,就是把原来的应用按照业务特点拆分成多个应用。比如一个大型电商系统可能包含用户系统、商品系统、订单系统、评价系统等等,我们可以把他们独立出来形成一个个单独的应用。多应用架构的特点是应用之间各自独立 ,不相互调用。 多应用虽然解决了应用臃肿问题,但应用之间相互独立,有些共同的业务或代码无法复用。 分布式架构 对于一个大型的互联网系统,一般会包含多个应用,而且应用之间往往还存在共同的业务,并且应用之间还存在调用关系。除此之外 ,对于大型的互联网系统还有一些其它的挑战,比如如何应对急剧增长的用户,如何管理好研发团队快速迭代产品研发,如何保持产品升级更加稳定等等 。 因此,为了使业务得到很好的复用,模块更加容易拓展和维护,我们希望业务与应用分离,某个业务不再属于一个应用,而是作为一个独立的服务单独进行维护。应用本身不再是一个臃肿的模块堆积,而是由一个个模块化的服务组件组合而成。 服务化 服务化的特点 上面介绍的分布式架构即服务化。我们再总结一下,服务化主要有如下特点:
服务化的好处 那么企业采用服务化有哪些好处呢?
服务化实现方式 如果要实现服务化的话,最常用的方式就是利用RPC框架。因为服务组件一般分布在不同的服务器上,所以要实现服务化需要解决的第一个问题就是RPC**远程服务调用**。类似于RPC方案有很多,比如:
服务化面临的挑战 上面提到要实现服务化首先需要解决远程服务调用问题,除此之外,还有很多其他问题需要解决。
服务治理 上面提到了服务化,其实要想服务化,服务治理是关键。那么有没有好的服务治理方案呢?答案是有的,而且很多人都在用这个框架,他就是-dubbo。dubbo就是一个带有服务治理功能的RPC框架。 dubbo提供了一套较为完整的服务治理方案,所以企业如果要实现服务化的话,dubbo 是很好的一个选择。这里简单介绍一下dubbo服务治理相关方案。 服务发现注册 服务治理领域最重要的问题就是服务发现与注册。dubbo中引入了一个注册中心的概念,服务的注册与发现主要就依赖这个服务中心。 dubbo注册中心服务注册发现的具体过程: 服务提供者启动,向注册中心注册自己提供的服务 消费者启动,向注册中心订阅自己需要的服务 注册中心返回服务提供者的列表给消费者 消费者从服务提供者列表中,按照软负载均衡算法,选择一台发起请求 服务监控 集群容错 负载均衡
(编辑:ASP站长网) |