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

2016.8.8, 深圳, Ken Fang

微服务设计是架构设计。

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

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

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

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

SaveSaveSaveSaveSaveSaveSaveSaveSaveSave

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏大魏分享(微信公众号:david-share)

Istio如何同时实现Hytrix|Ribbon|Zuul|微服务安全的功能?:为微服务引入Istio服务网格(下)

2603
来自专栏Laoqi's Linux运维专列

Nginx/LVS/HAProxy 负载均衡软件的优缺点详解(转自云栖社区)

1087
来自专栏学习有记

Python和SQL Server 2017的强大功能

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

RESTful API生命周期管理

介绍 应用程序编程接口(API)设计自计算机早期就已经存在 - 程序员不久之后就意识到明确定义的一组方法或功能有助于促进方案交流。虽然各种API之间的规格有所...

2267
来自专栏北京马哥教育

思维导图终极之战LVS负载均衡

昨天小伙伴们学习的是haproxy,作为负载均衡相比大家也很想在看一下lvs的思维导图。 下面我们开始今天的lvs思维导图之旅 一、 LVS简介 LVS是Li...

3657
来自专栏HBStream流媒体与音视频技术

基于Live555实现RtspServer及高清高码率视频传输优化

其实之前我就已经开发过一个RTSP Server程序,并且写了一篇文章进行了介绍“一个RtspServer的设计与实现和RTSP2.0简介”,不过当时开发的目的...

1161
来自专栏美码师

完美数据迁移-MongoDB Stream的应用

最近微服务架构火的不行,但本质上也只是风口上的一个热点词汇。 作为笔者的经验来说,想要应用一个新的架构需要带来的变革成本是非常高的。

882
来自专栏Netkiller

高级软件工程师(面试题)

高级软件工程师(面试题) 出题者:netkiller 出处:http://www.netkiller.cn/ 高级软件工程师 下面的面试题不分语言,适用于所有...

2943
来自专栏IT笔记

Grafana+Prometheus系统监控之webhook

概述 Webhook是一个API概念,并且变得越来越流行。我们能用事件描述的事物越多,webhook的作用范围也就越大。Webhook作为一个轻量的事件处理应用...

4713
来自专栏微服务

基于STS和JWT的微服务身份认证

自 Martin Fowler 提出微服务架构的概念后,这个名词就一直比较流行,总是成为众多技术论坛和公众号的讨论热点。很多互联网和软件公司都在将原有的整体架构...

2745

扫码关注云+社区