1 Matching Annotations
  1. Apr 2022
    1. 微服务架构也使用组件库,但是它把软件拆分成服务,并认为这是主要的组织形式。我们把 组件库定义为程序中相互关系、并使用内存中调用的组件,把 服务定义为进程间使用如Web请求服务或者远程调用来相互通信的组件。(这种定义的方式与其它面向对象程序中服务对象的概念是不一样的。)     把服务当成组件(而不是组件库)一个主要的原因是服务可以独立的部署。 如果你的应用由多个组件库组成并跑在一个进程中,那么任何组件的变更都将导致整体应用的重新发布。但是如果由许多服务构成的应用,你可以想像的到每个服务的变更仅需要发布相应的服务。 当然,这也不是绝对的,比如导致服务接口的变更的更新就需要相应服务的变化,但优秀微服务构架,会尽量避免这种服务间的耦合并完善服务的交互接口。     把服务当成组件的另一个考虑是这将拥有更新清晰的接口。许多开发语言并没有良好的定义公共接口的机制。通常只有文档和规范说明,让用户避免组件间会导致组件耦合的过度的依赖。不过服务由是是通过明确的远程接口调用,这个问题就很容易解决了。     使用服务也有它的不足之处。远程调用比进制内部调用更消耗性能,而且远程的API比较粗糙,难以使用。如果由于对组件的职责进行变更,影响到跨进程间的交互,那么这操作起来也比较困难。     第一个可能的特性,我们看到每个服务是运行在独立的进程上的。注意,这只是第一个可能的特性。服务也可以由多个进程组成,它们是同时开发和部署的,例如服务可能用到一个应用进制和一种数据禀。

      微服务架构,是把软件拆分成服务,并认为这是主要的组织形式。当然,微服务架构也使用组件库。

      我们把组件库定义为程序中相互关系,并使用内存中调用的组件,把服务定义为进程间调用。如,Web 请求服务或远程调用来相互通信的组件。

      把服务当成组件,而不是组件库,主要的原因是服务可以独立部署。

      如果应用由多组件组成,并跑在一个进程中,那任何组件的变更,都将导致整体应用的重新发布。但如果由许多服务构成的应用,每个服务的变更仅需发布相应的服务。

      这并不是绝对的,比如:导致服务接口变更的更新,就需要相应服务的变化。应尽量避免这种服务间的耦合,并完善服务的交互接口。

      服务当成组件的另一考虑是拥有更清晰的接口。服务是通过明确的远程接口调用。

      远程调用,比进程内部调用更消耗性能。