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

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 条评论
登录 后参与评论

相关文章

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

新数仓系列:Hbase周边生态梳理(1)

本文简单梳理下其中一个应用比较广的HBASE的生态,可能不全,有更多的请大家留言。具体HBASE的基本原理扫描大家可以自行百度下,另外,要系统掌握HBASE,推...

3847
来自专栏魏艾斯博客www.vpsss.net

搬瓦工常见名称解释:KVM/OVZ/CN2/QNET/MCOM 是啥意思

6165
来自专栏跟着阿笨一起玩NET

使用WCF实现SOA面向服务编程—— 架构设计

SOA本身就是一种面向企业级服务的系统架构,简单来说,SOA就是一种进行系统开发的新的体系架构,在基于SOA架构的系统中,具体应用程序的功 能是由 一些松耦合并...

511
来自专栏即时通讯技术

一文读懂高性能网络编程中的I/O模型

随着互联网的发展,面对海量用户高并发业务,传统的阻塞式的服务端架构模式已经无能为力。本文(和下篇《高性能网络编程(六):一文读懂高性能网络编程中的线程模型》)旨...

642
来自专栏SDNLAB

数据中心网络虚拟化 主流平台产品介绍

为了对数据中心网络虚拟化有个初步的认识,本文将对当前比较主流的几款商业平台进行介绍,包括VMware公司的网络虚拟化技术,IBM公司的Dove及开源的OpenD...

2895
来自专栏编程一生

《两地书》--Kubernetes(K8s)基础知识(docker容器技术)

  大家都知道历史上有段佳话叫“司马相如和卓文君”。“皑如山上雪,皎若云间月”。卓文君这么美,却也抵不过多情女儿薄情郎。

1904
来自专栏即时通讯技术

一文读懂高性能网络编程中的I/O模型

随着互联网的发展,面对海量用户高并发业务,传统的阻塞式的服务端架构模式已经无能为力。本文(和下篇《高性能网络编程(六):一文读懂高性能网络编程中的线程模型》)旨...

701
来自专栏大数据架构师专家

运维技能武器库

Bootstrapping: Kickstart、Cobbler、rpmbuild/xen、kvm、lxc、Openstack、 Cloudstack、Open...

832
来自专栏虚拟化云计算

嵌入式hypervisor为物联网而生

与数据中心不同, 物联网领域具有轻量级和灵活性的特殊要求,为了满足在物联网和嵌入式环境中的虚拟化需求,许多专门为嵌入式设备设计的hypervisor产生了,下面...

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

一个高级应用设计概要:完整设计一个高级应用-第一篇

版权说明:本文书写过程中参照了红帽的技术文档;本系列文章中的部分测试代码为红帽公司版权所有,因此不能提供源码文件。

692

扫码关注云+社区