微信号:freshmanTechnology

介绍:一群技术人的天地,每周3定期在线分享,覆盖各大城市,不怕起点、不惧权威!中生代创造未来!

微服务架构设计(一):核心概念&从既有的架构迁移到微服务的策略

2016-09-12 23:14 方俊贤
摘要:微服务设计不应是一个讲求标准答案, 简单粗暴的设计过程。而应该是一个考量各方因素下的一个决策的过程。所谓的微服务具体应包含哪些核心的概念?既有的架构迁移到微服务的 又有 哪些 策略?

微服务架构的核心概念

微服务设计是架构设计。

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

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


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

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



从既有的架构迁移到微服务的策略

在微服务的核心概念中, 最重要的核心概念便是: 边界上下文 (Bounded Context); 每一个微服务拥有各自的某一端到端业务场景 (功能)与数据 (数据库) 。


当将既有的架构迁移到微服务时, 常见的作法便是:

A.      只将既有架构的功能模块拆解成粒度较小的功能模块:

这样的作法, 其实, 实质上的意义是不大的。因为, 即使拆解成粒度较小的功能模块, 并且拆解后的各功能模块能互相的解藕, 但, 拆解后的各功能模块, 也许仍需共用数据库。所以, 当数据库即使只是修改某个数据表结构的某几个字段时, 也需同时修改多个功能模块。毫无疑问的, 这不仅会使产品开发的效率低落。拆解后的各功能模块, 在执行持续部署时, 将会有极大的概率会在某个阶段中断。同时, 也会为产品的架构引入新的风险, 甚至是致命的伤害。

B.      将既有架构的功能模块拆解成粒度较小的功能模块的同时, 也将既有数据库拆解; 使拆解后的各功能模块, 在拆解后, 便可拥有各自的数据库:

这样的作法, 所会带来的最大的问题是: 日后, 不论是发现拆解后的各功能模块, 粒度是过小或过大, 而需合并或再拆解功能模块时, 都将会有极大的概率, 会花费相当大的工作量在数据库的迁移上。


在将既有的架构迁移到微服务时, 架构师必需要考虑下列两个因素:

1.       我们其实是没法在一开始的时候、一步到位, 就能设计出正确、适当的微服务粒度的; 正确、适当的微服务粒度, 绝对是要经由不断的演进与学习而获得的。

2.       数据库的迁移风险极大; 一定要谋定而后动。


所以, 从既有的架构迁移到微服务的策略是:

I.       先以产品架构的性能、可靠性与安全性为首要的考量; 先拆解出粒度大的功能模块。

II.      再考量持续部署的独立性与对业务应变的能力, 而将必要的功能模块再拆解成粒度较小的功能模块。

III.     确定了所拆解的功能模块是正确、适当的微服务粒度后; 同时兼顾了性能、可靠性、安全性、持续部署的独立性与对业务应变的能力; 再进行数据库的拆解与迁移; 使各功能模块 (微服务) 真正拥有各自的数据库。最终, 使各功能模块 (微服务) 真正拥有正确、适当的边界上下文 (Bounded Context) 。


架构师应一直铭记在心:

微服务正确、适当的边界上下文 (Bounded Context), 绝对是要经由不断的演进与学习而获得的; 没有标准答案, 没有一步到位的。

本文转自自CSDN博客  方俊贤_Ken

原文链接:

http://blog.csdn.net/featuresoft/article/details/52156360

http://blog.csdn.net/featuresoft/article/details/52156361

『中生代技术』


连接技术大咖的桥梁
促进科技技术的交流


微信号:freshmanTechnology

 
中生代技术 更多文章 中生代技术群第六期分享预告 从0到1的电商架构,初期该怎么做? 高效运维之员工的四大误区及解决之道 高效运维之Redis集群技术及Codis实践 alinode-基于Node.js运行时的应用性能管理解决方案
猜您喜欢 琴棋书画样样精通?除了这四大才艺,Google 的人工智能还会什么 【从0到1】2015,移动互联网十大趋势预测 【干货】硬啃 :读完这100篇论文,你就能成大数据高手! iOS 代码实践总结 5个最优秀的Java和C#代码转换工具