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