微服务架构: 微服务架构的核心概念 ( 一 )

导语

我将发表一系列关于微服务的文章, 从探讨微服务的架构开始, 到打造微服务软件架构的工程实践。 期望, 能激发起大家对微服务的兴趣与重视。 更期待大家的交流。

前言

经过了半个多世纪的软件开发, 所积累到的知识与经验, 我们终于构造了可扩展的系统架构; 云平台。

然而, 在这可扩展的云平台上, 我们又该如何打造我们自身的产品软件架构? 使得我们的产品软件架构, 可充份的运用云平台, 而使得我们自身的产品, 也能随著外部世界的变化, 而扩展、而适应变化。

微服务, 提供了一个 "架构模式"; 使得我们得以参考这一架构模式, 而去设计一可扩展、可适应变化的产品软件架构。

微服务设计是架构设计。

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

本文

在探讨微服务架构前, 我们先来探讨下, 所谓的微服务具体应包含哪些核心的概念?

I. 分布式 (Distributed):

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

II. 分别部署 (Separately Deploy):

微服务架构的产品或许会有数百甚至数千个微服务所构成。所以, 部署微服务时, 便很难经由手工来完成, 而必须相当程度的依赖自动化的 DevOps 工具。

III. 服务组件 (Service Component):

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

微服务共分为两大类:

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

b如: 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. 开发新的微服务优于在既有的微服务上不断的加新的场景或功能:

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

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏云计算

了解云容器的四方面

对容器的大量需求使企业推出了各种云容器服务。而市场上这么多的选择,很难决定去使用哪一个容器平台或工具。在你了解云容器技术的选择之前,你必须先确定容器是否值得您的...

1910
来自专栏IT技术精选文摘

关于性能优化的一些实践

在海量并发业务的场景下,比如电商抢购、微信红包这样的场景下,我们经常会遇到各种各样的性能问题,在应对这些问题的时候,应该有怎样的方法论去指导我们解决问题,基于这...

893
来自专栏Spark学习技巧

消息队列服务Kafka揭秘:痛点、优势以及适用场景

摘要:消息队列Kafka是一个分布式的、高吞吐量、高可扩展性消息队列服务,广泛用于日志收集、监控数据聚合、流式数据处理、在线和离线分析等,是大数据生态中不可或缺...

843
来自专栏云计算D1net

容器 VS. 虚拟机:云中应该使用哪一种?

在开足马力使用容器之前,了解容器与虚拟机在私有云、公共云以及混合云部署之间的区别是至关重要的。 虽然目前大多数的云部署都是基于虚拟机的,但是容器技术为云用户带来...

3836
来自专栏程序你好

微服务Microservices——应用架构的未来

能够构建、演变和扩展大型应用程序对于组织来说是至关重要的,但是所涉及的挑战使其成为一项困难的任务。正因为如此,微服务已经成为构建现代云应用的主导模式,它将单个组...

872
来自专栏企鹅号快讯

分布式架构的套路No.74

今天小蕉跟大伙一起聊聊分布式系统的架构的套路。在开始说套路之前,大家先思考一个问题,为什么要进行分布式架构? 大多数的开发者大多数的系统可能从来没接触过分布式系...

3579
来自专栏云计算D1net

云存储取得的突破性应用 推动云安防落地

近年来,随着海量视频信息的快速增长,传统的安防技术越来越难以满足部分行业在传输、存储及大数据计算分析上的需要,或者说很难以更低的成本、更灵活的扩展性、更健壮更可...

3164
来自专栏开发者

关于性能优化的一些实践

在海量并发业务的场景下,比如电商抢购、微信红包这样的场景下,我们经常会遇到各种各样的性能问题,在应对这些问题的时候,应该有怎样的方法论去指导我们解...

2584
来自专栏SDNLAB

容器和云给网络带来巨大的压力

鉴于开发人员已经开始采用敏捷、方便的可编排技术,因此会越来越多地采用基于容器的应用程序。但是当这些应用程序进入生产阶段时,他们的编排解决方案对操作复杂性产生了相...

3259
来自专栏大数据和云计算技术

NoSQL 还是 SQL ?这一篇讲清楚

1.NoSQL的诞生原因 随着互联网快速发展,各种类型的应用层出不穷,所以导致在这个云计算的时代,对技术提出了更多的需求,主要体现在下面这四个方面: 低延迟的读...

2944

扫码关注云+社区