元数据驱动的微服务架构(上)

本次分享有两个部分:

  1. 微服务架构需要元数据
  2. 介绍微服务与元数据的关系。

一、微服务架构需要元数据

企业IT架构已经发展了多个阶段,一方面是服务化架构的发展,在SOA阶段主要解决应用间集成问题,但随着企业业务的发展,单个应用逐渐成为“巨石型”应用,难以扩展也难以维护。

微服务架构应运而生,微服务架构专注于单个应用的内部,将“巨石”应用拆分成为多个微服务,以微服务为单独单元开发运营。另一方面是模型化架构式的发展,模型驱动工程也在不断发展,从MDA(模型驱动架构)全面的完全模型自动化,到DSM(特定领域建模)针对特定领域的建模,再发展到DDD(领域模型驱动设计),模型的作用变得更加特定化和轻量化。

服务化架构和模型化架构其实是统一的。在微服务架构中微服务的粒度小,数量多,微服务的设计与微服务之间的连接需要一套规范,同时需要一套可以对话的统一“语言”。

传统的模型方式的核心目标是能够自动生成代码,故定义过于复杂。而微服务间的“语言”的目标与传统不同,用元数据作为“语言”驱动整个微服务架构是不错的选择。

我们看看元数据表示了什么内容,我在之前一篇文章中从心理学的角度详细说明了元数据是什么。(若阅读此文,请微信搜索文章标题“轻松理解元数据,只需懂点心理学”)元数据就是计算机的认知维度,可以说,掌握了元数据就掌握了信息的维度,只有充分利用好元数据(也就是信息的维度),通过合理的元数据建模(维度整合),对元数据进行科学管理(维度完善),才能让让计算机更好地认知企业系统。


元数据管理的核心内容是,信息的概念和信息之间的连接。概念表示对某个业务所有维度的集合,连接是对业务维度之间关系的描述。通过这样的描述,能够使元数据成为微服务直接对话的“语言”,还能够通过“语言”规范微服务体系的设计。

二、微服务与元数据的关系

定位模型与元数据的概念之前,我们不得不提到MOF(元对象设施或者元对象机制 MetaObject Facility),它是OMG(国际标准化组织)元模型和元数据的存储标准,提供在异构环境下对元数据知识库的访问接口。我们可以看到每个层次的上一层是下一层的模型,本层次的描述语言在它的上一层模型中。

我们今天重点关注M1层元数据,也就是通常说的“数据模型层”。M1层(元数据)对应在日常我们项目开发过程中进行的ER模型图模型设计。也就是说我们进行所有的数据层设计其实都是元数据的建模过程。

我们来看一下平时是如何进行模型设计的,也就是进行元数据的设计,数据的描述。我们一般建模过程会将其分解成更小的、更简单的元素,通过多个模型之间的关系描述复杂的事物逻辑。一般从需求开始,无论是用户的需求还是技术需求,能力是实现需求的桥梁与纽带,借助现有的技术手段进行实现的支撑。随着建模过程逐渐深入,建模可以分为概念模型-逻辑模型-物理模型,层层递进最终物理模型会确定数据库实现方式,将数据表固化到数据库中。

我们再来看建模的手段工具,最有效的简化方式是图形建模,也就是我们通常所说的ER图建模。多数建模方法都建立在可视化语言的基础上。比如UML实体-关系图建模,这就是最常见的语义模型建模方法。 基于语义分析模型的元数据模型,主要是建立模型的实体与实体之间的关系,包括元数据模型之间关系的建立,元数据之间的输入输出接口等。

那么问题就来了,之前我们碰到的数据往往是集中存储的。如果数据模型的存储是分散的,多个元数据模型群之间的数据描述是不一致的,多个模型之间互相访问与数据共享应该遵照什么样的标准呢?我们是不是也要设计一套符合所有模型之间交互的语义模型?这种模型之间的所有交互需求都可以满足吗?

确实是有不同数据模型之间统一标准相互访问的机制。答案也是肯定的。XMI 是 OMG在元数据交换方面的最重要标准之一,同时也是 W3C 认可的标准。允许 MOF元数据(即遵从 MOF 或基于 MOF 的元模型的元数据)以流或文件的形式按照 XML 的标准格式进行交换。

在微服务中每个服务都有自己的数据库这种思路与企业级的传统数据建模过程不同,每个微服务中需要建立自己的数据模型。各微服务的接口API需要定义元数据,接口需要清晰的元数据模型,对象、属性。也就是我们需要元数据的原因,我们需要建一套完整的元数据模型机制,这也就是元数据与微服务之间的关系所在。


关于作者:

王轩EAII-企业架构创新研究院 专家委员

现任普元软件产品部副总兼大数据产品线总经理,2010年加入普元,全面主持普元大数据产品的研发、拓展及团队管理工作。十年大型企业信息化架构设计与建设经验,曾任中国人民银行核心平台架构师。主持参与了国家开发银行大数据项目、中国人民银行软件开发平台、国家电网云计算平台等大型项目建设。王轩对大数据行业有着深入的研究和洞察,并对企业信息化平台建设,企业云计算及大数据平台建设有着丰富经验。


关于EAII

EAII(Enterprise Architecture Innovation Institute)企业架构创新研究院,是专注于企业架构与业务创新领域的研究机构,致力于金融、电信、能源与政务等行业领域的企业软件架构优化设计与 创新研究,以及分布式计算、服务构件技术、可视化技术、业务流程管理、内存计算、企业移动计算、数据治理等领域的技术研究。

本文转载自微信公众号 中生代技术 freshmanTechnology

时间: 2024-11-10 05:29:50

元数据驱动的微服务架构(上)的相关文章

视觉中国:基于容器云的同城双活微服务架构上云实践

本文正在参加"最佳上云实践"评选,来给我们投票吧:https://yq.aliyun.com/activity/158(编号7) 视觉中国集团(Visual China Group)创立于2000年6月,是中国领先的视觉影像产品和服务提供商.视觉中国集团是以"视觉创造价值,视觉服务中国"为愿景的A股唯一互联网文化创意上市公司(股票代号000681,股票简称:视觉中国).视觉中国集团以"视觉内容与服务"."视觉社区"和"

《Spring Cloud与Docker微服务架构实战》配套代码

不才写了本使用Spring Cloud玩转微服务架构的书,书名是<Spring Cloud与Docker微服务架构实战> - 周立,已于2017-01-12交稿.不少朋友想先看看源码,现将代码放出. 本次放出的代码: 共计70+个DEMO 覆盖Eureka.Ribbon.Feign.Hystrix.Zuul.Spring Cloud Config.Spring Cloud Bus.Spring Cloud Sleuth.Docker.Docker Compose等. 1-11章代码地址: ht

如何提高微服务架构的可用性

业界通常用多少个9来衡量系统的可用性,如99.99%表示一年中有1小时左右的不可用时间.任何一个服务的可用性都不会是100%,意味着在服务运行时间里还是有可能发生故障.当把功能集中且运行在同一个应用中的单体架构拆分成多个相互独立的微服务架构后,虽然可以降低一损俱损的全局性故障风险,但由于微服务之间存在大量的依赖关系, 随着微服务个数的增多,依赖关系也将会变得越来越复杂,而且每个微服务都有可能发生故障,如果不能做好相互依赖的隔离,避免故障的连锁反应,结果可能比单体更糟糕.假设有100个微服务,并且

基于微服务架构,实解容器级DevOps平台的建设

导读:本文以"实践过程中问题与思考"为主体,与大家分享其中的过程和经验,希望大家在后续的工作中能够避免相关问题,形成更佳实践. 首先简单说下我们要做什么,不谈理念,不谈哲学,我们要做一款基于微服务架构,可以同时运行在公有云和私有云上的容器云平台,以DevOps为目标,提升协作效率,快速交付. 为什么选择阿里云 现在的公有云如雨后春笋,国外如AWS.Azure.Bluemix,国内如阿里云.腾讯云.DaoCloud.goodrain等,都可以给大家提供丰富的云基础设施和上层服务,那为什么

亿级流量电商详情页系统实战:缓存架构+高可用服务架构+微服务架构

<缓存架构+高可用服务架构+微服务架构>深入讲解了亿级流量电商详情页系统的完整大型架构.同时最重要的是,在完全真实的大型电商详情页系统架构下,全流程实战了整套微服务架构,包含了基于领域驱动设计进行微服务建模.Spring Cloud.基于DevOps的持续交付流水线与自动化测试套件.基于Docker的自动化部署.此外,还包含了大型电商详情页系统架构中的多种复杂架构设计的详细介绍. <亿级流量电商详情页系统实战(第一版)>的内容,主要是基于简化以后的大型电商详情页系统的背景,重点包含

微服务架构的核心要点和实现原理

微服务架构中职能团队的划分 传统单体架构将系统分成具有不同职责的层次,对应的项目管理也倾向于将大的团队分成不同的职能团队,主要包括:用户交互UI团队.后台业务逻辑处理团队与数据存取ORM团队.DBA团队等.每个团队只对自己分层的职责负责,并对使用方提供组件服务质量保证.如果其中一个模块化组件需要升级.更新,那么这个变更会涉及不同的分层团队,即使升级和变更的改变很小,也需要进行跨团队沟通:需求阶段需要跨团队沟通产品功能,设计阶段需要跨团队沟通设计方案,开发阶段需要跨团队沟通具体的接口定义,测试阶段

微服务架构的优势与不足

微服务正在博客.社交媒体讨论组和会议演讲中获得越来越多的关注,在Gartner的2014 Hype Cycle上它的排名非常靠前.同时,软件社区中也有不少持怀疑论者,认为微服务不是什么新东西.Naysayers认为这就是SOA架构的重新包装.然 而,尽管存在着不同的争论,微服务架构模式却正在为敏捷部署以及复杂企业应用实施提供巨大的帮助. 首先我们看看为什么要使用微服务. 开发单体式应用 假设你正准备开发一款与Uber和Hailo竞争的出租车调度软件,经过初步会议和需求分析,你可能会手动或者使用基

正在考虑微服务架构的松耦合?小心这些陷阱!

本文讲的是正在考虑微服务架构的松耦合?小心这些陷阱![编者的话]本文阐述了作者在构建松耦合的微服务架构中遇到的一些挑战,并给出了相应的方法,包括:如何处理多个微服务间共享数据的场景,如何演进微服务API,如何处理微服务安全,以及如何组合微服务等. 微服务是一种新的架构,它使用简单.轻量.松耦合的服务来构建系统,这些服务彼此可以独立开发和发布. 如果你还不了解这些基础概念,请阅读Martin Fowler的文章.如果你想拿它和SOA进行比较,请看Don Ferguson的演讲.Martin Fow

DockOne微信分享(九十七):现有系统实施微服务架构改进经验分享

本文讲的是DockOne微信分享(九十七):现有系统实施微服务架构改进经验分享[编者的话]微服务是最近非常热门的话题了,它带来的好处吸引不少互联网公司对现有项目进行微服务架构改进. 本次分享是博主根据自身的项目经验,介绍如何对现有架构进行调整,总结这过程中的相关技术选型,以及如何实施技改,并分享最终取得的非常让人意外的成果. 大家好,我是凤凰牌老熊,很高兴能有机会和大家交流关于微服务系统建设相关的话题. 近期和微服务相关的话题非常地火,大家看到的各种开发技术网站,微服务都是一个热门的话题. 今天