小李的便利店

悠优酸幽

微服务架构的概念

微服务设计是架构设计

所以, 微服务设计不应是一个讲求标准答案, 简单粗暴的设计过程。而应该是一个考量各方因素下的一个决策的过程。

I.        分布式 (Distributed):
微服务与微服务间分布式调用最主要的概念便是: protocol-aware heterogeneous interoperability(协议感知的异构互操作性); 各微服务可各自拥有自身的 platform (Java,C#, Scala…等等), 但, 各微服务间却只能藉由单一共同的协议 (protocol); 如: REST; 进行分布式的调用。

II.      分别部署 (Separately Deploy):

微服务架构的产品或许有百个甚至千个服务,所以,部署微服务时,很难由手工部署,我们通常会依赖自动化的 DevOps 工具进行部署。

III.    服务组件 (Service Component):

微服务是以服务组件, 而不是以类或模块的方式体现; 每个服务组件会包含一个或多个类或组件。

微服务共分为两大类:

A.      Infrastructure Services: 主要是为产品中其他的微服务提供服务; 被产品中其他的微服务直接的调用。

    如: login service 便是一Infrastructure Services 的例子; 主要是为产品中其他的微服务提供产品登入的服务。

所以, Infrastructure Services 对产品外部的使用者界面、系统、设备都是不可见的, 也就是说, 产品外部的使用者界面、系统、设备是无法经由 api layer 来找到 Infrastructure Services 的。

B.      Functional Services: 主要是为产品外部的使用者界面、系统、设备提供某一端到端业务场景的服务。

所以, 相对于 Infrastructure Services, Functional Services 对产品外部的使用者界面、系统、设备而言, 都是可见的。也就是说, 产品外部的使用者界面、系统、设备是经由 api layer 来找到 Functional Services 的。

IV.    边界上下文 (Bounded Context):

微服务的边界上下文包含:
A.   某一端到端业务场景 (功能) 。
B.   数据 (数据库) 

微服务的边界上下文提供了一个很重要的微服务概念:微服务应能独立各自的开发、测试, 并且当发布、部署后, 亦不致影响到其他微服务的功能或运作

V.  不共享任何事物 (Share Nothing):

因为, 微服务间共享任何的事物, 将会造成微服务间的依赖。
所以, 微服务间应避免共享任何的事物。

VI.    api layer:

api layer 主要是在微服务与微服务外部的使用者界面、系统或设备之间构建:

A.      endpoint proxy: 隐藏各微服务的 endpoint。
B.      load balancer: 多节点间的负载均衡。

VII.  开发新的微服务优于在既有的微服务上不断的加新的场景或功能:

当某个微服务开发完后, 便应避免不要再在此微服务上, 不断的加新的场景或功能; 新的场景或功能应该是属于另一个新的微服务。

《微服务架构的概念》

点赞

发表评论

电子邮件地址不会被公开。