程序员疯子的博客-Code is Art, Code is Poetry!

谈谈服务治理与微服务

近期都在大谈微服务,本人也在做相关的工作已经两年左右了,做了一个微服务的分享,整理了这篇文章,有问题可以在下面留言,可以和大家一起讨论。

先简单介绍了互联网架构的演变,进而介绍了服务化,最后再介绍微服务,微服务是服务治理的升级也是互联网架构的进一步延伸。

互联网架构演变

单体体架构

在计算机软件发展早期,一般桌面软件都是采用这种架构,不管是界面还是业务处理还是数据处理都放到一个包中。这种其实谈不上架构,但也可以说是很好的架构,因为它足够简单。 如下图:

image
image

  • 单体式应用的优点明显:
    现有IDE都是集成开发环境,非常适合单体式应用,开发、编译、调试一站式搞定。
    一个应用包含所有功能,容易测试和部署。
    运行在一个物理节点,环境单一,运行稳定,故障恢复简单。
  • 单体式应用的缺点也明显:
    业务边界模糊,模块职责不清晰,当系统逐渐变大,代码依赖复杂,难以维护。
    所有人同时在一个工程上开发,容易发生代码修改冲突,依赖复杂导致项目协调困难,并且局部修改影响不可知,需要全覆盖测试,需要重新部署,难以支持大团队并行开发。
    当系统很大时,编译和部署耗时。
    应用水平扩展难,一方面状态在应用内部管理,无法透明路由;另
    一方面,不同模块对资源需求差异大,当业务量增大时,一视同仁地为所有模块增加机器导致硬件浪费。

MVC架构

但随着浏览器的出现便产生了web应用,web应用的特点是界面部分是显示在浏览器中,服务处理是在服务容器中的,页面显示一般用css+js+html技术来处理,而后端可以用JavaPHP等语言,这就产生了前后端分离。对于web系统,一体架构难以满足前后端分离的开发需求,因而便产生了MVC架构。
为什么我把Mvc但那处处呢,因为他也有划时代的意义,其实从大方向讲MVC架构也是单体架构的一种

MVC架构如下图:
image

MVC才算的上真正意义上的架构,因为它除了解决了前后端分离问题,还引入了一种全新的开发模式,用一种业务逻辑、数据、界面显示分离的方法组织代码,使得整个应用层次更加分明,而且各个层次之间不但减低了耦合性,还提高了各个层次的可重用性。

但随着应用规模的不断扩大,应用模块不断增加,整个应用也显得越来越臃肿,维护起来也更加困难,因此便又产生了多应用架构

多应用架构

多应用架构很简单,就是把原来的应用按照业务特点拆分成多个应用。比如一个大型电商系统可能包含用户系统、商品系统、订单系统、评价系统等等,我们可以把他们独立出来形成一个个单独的应用。多应用架构的特点是应用之间各自独立 ,不相互调用。如下图:
image

多应用虽然解决了应用臃肿问题,但应用之间相互独立,有些共同的业务或代码无法复用。

分布式架构

对于一个大型的互联网系统,一般会包含多个应用,而且应用之间往往还存在共同的业务,并且应用之间还存在调用关系。除此之外 ,对于大型的互联网系统还有一些其它的挑战,比如如何应对急剧增长的用户,如何管理好研发团队快速迭代产品研发,如何保持产品升级更加稳定等等 。

因此,为了使业务得到很好的复用,模块更加容易拓展和维护,我们希望业务与应用分离,某个业务不再属于一个应用,而是作为一个独立的服务单独进行维护。应用本身不再是一个臃肿的模块堆积,而是由一个个模块化的服务组件组合而成。

在分布式应用架构中,应用相互独立,每个应用代码独立开发,独立部署,应用通过有限的API接口互相关联。API接口属于应用一部分,一般和表示层处于同一层次,两者共享业务逻辑层,API和表示层采用同样的web端技术,通讯协议一般使用HTTP,数据格式是JSON,应用集成方式比较简化。

分布式架构首先对系统按照业务进行垂直切分,把系统切分为不同应用,针对资源需求特点(比如CPU/IO/存储密集型),通过加强硬件配置满足不同应用的需求,避免一刀切方式带来的资源浪费。
image

技术上,API采用标准的HTTP/JSON进行通讯,调用双方实现难度都不大,但是API一般是“裸奔”的,在系统层面,调用依赖关系不透明,调用可靠性缺乏保障,因此只适用应用之间依赖链路少,调用量不大的系统,即应用之间耦合确实够松的系统。

SOA架构

有人说SOA就是分布式,其实这个界限有点模糊,不过相比较普通API方式,SOA架构更进一步

  • 每个service都是浓缩的精华,聚焦某方面核心业务,同时以复用的方式供整个系统共享。
  • 服务作为独立的应用,独立部署,接口清晰,很容易做自动化测试和部署。
  • 服务是无状态的,很容易做水平扩展;通过容器虚拟化技术,实现故障隔离和资源高效利用,业务量大的时候,加机器即可。
  • 基于SOA的系统可以根据服务运行情况,灵活调控服务资源,包括服务上下架、服务升降级等,使系统真正具备可运营的能力。
  • 当然天下没有免费的午餐,SOA也带来了额外复杂性和弊端:
  • 系统依赖复杂,给开发/测试/部署带来一系列挑战。
  • 端到端的调用链路长,可靠性降低,依赖网络状况、服务框架及具体service的质量。
  • 分布式数据一致性和分布式事务支持困难,一般通过最终一致性简化解决。
    端到端的测试和排障复杂,SOA对运维提出更高要求。
    例子如下:

image

  • SOA的特点
  • 可从企业外部访问
  • 随时可用
  • 粗粒度的服务接口分级
  • 松散耦合
  • 可重用的服务
  • 服务接口设计管理
  • 标准化的服务接口
  • 支持各种消息模式
  • 精确定义的服务契约
    说起SOA 我第一想到的是企业服务总线(ESB)

    SOA的好处

    那么SOA有哪些好处呢?

  • 架构上系统更加清晰

  • 核心模块稳定,以服务组件为单位进行升级,避免了频繁发布带来的风险
  • 开发管理方便
  • 单独团队维护、工作分明,职责清晰
  • 业务复用、代码复用
  • 非常容易拓展
  • SOA实现方式

如果要实现SOA的话,最常用的方式就是利用RPC框架。因为服务组件一般分布在不同的服务器上,所以要实现服务化需要解决的第一个问题就是RPC远程服务调用。类似于RPC方案有很多,比如:

  • Java RMI
  • WebService
  • Hessian
  • Thrift

服务化面临的挑战

上面提到要实现服务化首先需要解决远程服务调用问题,除此之外,还有很多其他问题需要解决。

  • 服务越来越多,配置管理复杂
  • 服务间依赖关系复杂
  • 服务之间的负载均衡
  • 服务的拓展
  • 服务监控
  • 服务降级
  • 服务鉴权
  • 服务上线与下线
  • 服务文档

  • 有时间我专门有写一篇关于RPC的文章
    我们接着往下说,有了服务 就需要治理跟维护 下面我们讲一讲服务治理

服务治理

上面提到了服务化,其实要想服务化,服务治理是关键。那么有没有好的服务治理方案呢?答案是有的,而且还很多,比如: ICE dubbo springcloud 魔毯 等等
下面我们简单说说服务治理所需要的

  • 集中的注册中心和存储库,以查找和发布与服务相关的构件和元数据。
  • 查找正确的授权服务。
  • 避免重复工作。
  • 促进重用。
  • 确定服务在 SOA 生命周期中的当前状态。
  • 为服务订阅者提供可见性。
  • 确定相关服务和更改某个服务所造成的影响。
  • 传达对服务所做的更改。
  • 用于联系和强制应用于某个服务的策略的机制。策略通过使用治理框架来定义。
  • 具有生命周期感知性的可自定义系统,该系统在生命周期中发生阶段更改时触发验证,以便能够自动化逐个阶段的治理验证。
  • 在理想的情况下,注册中心应该针对SOA运行时进行优化,以便能够在运行时期间,使用存储在注册中心的元数据来通过动态路由充实内容。
    详细的各个中间件的原理以及怎么解决服务治理的我有专门写文章
    继续往下说 从去年微服务突然火了起来,咱们看看微服务

    微服务

在很多人都在谈微服务,那么到底什么是微服务呢?这里谈谈我对微服务的理解。

微服务有两个核心:

  • 微:服务的粒度要细,即服务要细化到API(要做到这一点很不容易,比如服务的切分)
  • 服务:提供好服务,要让用户感到好用

上面两个核心总结起来,可以用下面这幅图表示:
image

从上面这幅图看出,微服务特别简单(好的架构就应该简单),我们把服务再拆分成一个个API,API是一个完整的功能。然后我们把API扔到一个“云上”,然后用户就可以到“云上”获取所有API的服务,这个“云”保证能提供好的服务。

我们可以看到,有了微服务之后,服务对用户来说变得特别简单。不再需要去注册中心查找服务,不再去做鉴权处理,不用担心服务挂掉,不用担心不会使用服务,所有的问题这个“云”都解决了。这也是微服务的核心之一,提供好服务。
image

说到这里,大家就应该大体知道该怎么做微服务了 其实“云”是最关键的。
微服务的关键是服务网关,所以,上面提到的“云”就是服务网关。要做微服务,我们先定义一下微服务需要具备的特点。

微服务的特点
  • 服务需要再细化成API(服务接口——>服务API)

  • 每个服务由一组API组成

  • 以API形式对外提供统一格式的服务
  • 使用者无需任何配置,直接调用(http)
  • 完整的API文档
  • API服务安全可靠稳定
  • 总结:大概是15年8月接触SOA吧以上就是我的粗浅理解,下一篇我会介绍服务治理的几个框架
Fengzijk wechat
欢迎您扫一扫上面的微信公众号,订阅我的公众号!
您的支持将鼓励我继续创作