微服务设计是架构设计。
所以, 微服务设计不应是一个讲求标准答案, 简单粗暴的设计过程。而应该是一个考量各方因素下的一个决策的过程。
所以, 在探讨微服务设计前, 我们先来探讨下, 所谓的微服务具体应包含哪些核心的概念?
微服务共分为两大类:
A. Infrastructure Services: 主要是为产品中其他的微服务提供服务; 被产品中其他的微服务直接的调用。
如: login service 便是一Infrastructure Services 的例子; 主要是为产品中其他的微服务提供产品登入的服务。
所以, Infrastructure Services 对产品外部的使用者界面、系统、设备都是不可见的, 也就是说, 产品外部的使用者界面、系统、设备是无法经由 api layer 来找到 Infrastructure Services 的。
B. Functional Services: 主要是为产品外部的使用者界面、系统、设备提供某一端到端业务场景的服务。
所以, 相对于 Infrastructure Services, Functional Services 对产品外部的使用者界面、系统、设备而言, 都是可见的。也就是说, 产品外部的使用者界面、系统、设备是经由 api layer 来找到 Functional Services 的。
A. 某一端到端业务场景 (功能) 。
B. 数据 (数据库) 。
微服务的边界上下文, 使得每一个微服务拥有各自的某一端到端业务场景 (功能)与数据 (数据库) 。
更重要的是: 当微服务X需调用微服务Y, 则微服务X 与微服务Y的边界上下文, 将可避免或降低发生, 当微服务Y 运作失败时, 会影响到微服务 X。
所以, 微服务的边界上下文提供了一个很重要的微服务概念：微服务应能独立各自的开发、测试, 并且当发布、部署后, 亦不致影响到其他微服务的功能或运作。
所以, 微服务间应避免共享任何的事物; 如:继承结构下的抽象接口, 服务, 模块, utility, 类, 数据 (数据库)…等等。
A. endpoint proxy: 隐藏各微服务的 endpoint。
当某个新增的场景在某个新的微服务上开发完后, 这个新的微服务便会有了新的 endpoint。 而api layer 便可将此微服务外部的使用者界面、系统或设备导向此新的微服务上的 endpoint。使得微服务外部的使用者界面、系统或设备可在不需要有任何修改的情况下, 便可以使用此新的微服务。而当微服务外部的使用者界面、系统或设备发现此新的微服务不适用时, api layer 便可将微服务外部的使用者界面、系统或设备导向旧的微服务上的 endpoint, 而使得新的微服务, 对微服务外部的使用者界面、系统或设备而言, 变得不可见。
B. load balancer: 多节点间的负载均衡。
本文作者:
方俊贤 (Ken Fang), 曾任职于 IJI, Rational, Telelogic, Borland◦ 有将近二十年在半导体, 电信产业与军事研究单位, 从事软件工程与精益敏捷开发相关咨询服务的经验。 主要专长是精益敏捷开发, 有价值的产品需求挖掘, 使用者行为场景分析, 动态注入框架设计, ROA, 既有软件架构优化, 探索式测试, 敏捷测试与持续集成。
本文转载自 方俊贤_Ken 的 CSDN 博客 原文链接： http://blog.csdn.net/featuresoft/article/details/52156360
所以, 微服务设计不应是一个讲求标准答案, 简单粗暴的设计过程。而应该是一个考量各方因素下的一个决策的过程。
所以, 在探讨微服务设计前, 我们先来探讨下, 所谓的微服务具体应包含哪些核心的概念?
I. 分布式 (Distributed):
微服务与微服务间分布式调用最主要的概念便是: protocol-aware heterogeneous interoperability; 各微服务可各自拥有自身的 platform (Java,C＃, Scala…等等), 但, 各微服务间却只能藉由单一共同的协议 (protocol); 如: REST; 进行分布式的调用。II. 分别部署 (Separately Deploy):
微服务架构的产品或许会有数百甚至数千个微服务所构成。所以, 部署微服务时, 便很难经由手工来完成, 而必须相当程度的依赖自动化的 DevOps 工具。
| Service Registry And Discovery | Deployment | Monitoring |
| Zookeeper Doozer Etcd SmartStack Eureka NSQ Serf Spotify DNS SkyDNS Consul |
Cloud Foundry Gradle Docker Docker Hub Docker Machine Kitematic Docker Compose Docker Swarm AWS Jenkins Continuum Hudson Artifactory Terraform Grunt OpenShift |
SonarCube Logstash New Relic Graphite Mesosphere / DCOS Winston Hystrix |
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. 数据 (数据库) 。
微服务的边界上下文, 使得每一个微服务拥有各自的某一端到端业务场景 (功能)与数据 (数据库) 。
更重要的是: 当微服务X需调用微服务Y, 则微服务X 与微服务Y的边界上下文, 将可避免或降低发生, 当微服务Y 运作失败时, 会影响到微服务 X。
所以, 微服务的边界上下文提供了一个很重要的微服务概念：微服务应能独立各自的开发、测试, 并且当发布、部署后, 亦不致影响到其他微服务的功能或运作。
V. 不共享任何事物 (Share Nothing):
因为, 微服务间共享任何的事物, 将会造成微服务间的依赖。所以, 微服务间应避免共享任何的事物; 如:继承结构下的抽象接口, 服务, 模块, utility, 类, 数据 (数据库)…等等。
VI. api layer:
api layer 主要是在微服务与微服务外部的使用者界面、系统或设备之间构建:A. endpoint proxy: 隐藏各微服务的 endpoint。
当某个新增的场景在某个新的微服务上开发完后, 这个新的微服务便会有了新的 endpoint。 而api layer 便可将此微服务外部的使用者界面、系统或设备导向此新的微服务上的 endpoint。使得微服务外部的使用者界面、系统或设备可在不需要有任何修改的情况下, 便可以使用此新的微服务。而当微服务外部的使用者界面、系统或设备发现此新的微服务不适用时, api layer 便可将微服务外部的使用者界面、系统或设备导向旧的微服务上的 endpoint, 而使得新的微服务, 对微服务外部的使用者界面、系统或设备而言, 变得不可见。
B. load balancer: 多节点间的负载均衡。
VII. 开发新的微服务优于在既有的微服务上不断的加新的场景或功能:
当某个微服务开发完后, 便应避免不要再在此微服务上, 不断的加新的场景或功能; 新的场景或功能应该是属于另一个新的微服务。
本文作者:
方俊贤 (Ken Fang), 曾任职于 IJI, Rational, Telelogic, Borland◦ 有将近二十年在半导体, 电信产业与军事研究单位, 从事软件工程与精益敏捷开发相关咨询服务的经验。 主要专长是精益敏捷开发, 有价值的产品需求挖掘, 使用者行为场景分析, 动态注入框架设计, ROA, 既有软件架构优化, 探索式测试, 敏捷测试与持续集成。
本文转载自 方俊贤_Ken 的 CSDN 博客 原文链接： http://blog.csdn.net/featuresoft/article/details/52156360
