面向微服务的企业云计算架构转型

云计算的本质是提高效率,而不是降低成本,公有云就是要提高社会的效率,私有云就是要提高 IT 的效率。

从这个角度看,实施云计算就是做精益运营,而微服务架构为精益运营提供了架构上的保证,因为微服务是小的、容易变化的、容易控制的。

大家好,我是焦烈焱,今天主要介绍普元利用云计算模式,帮助企业实施数字化转型过程中,在技术上遇到的挑战,以及我们解决问题的方法。

首先解释一下什么是数字化?数字化就是把人、事/物和商业联系起来,Garnter 提到未来的企业都是数字化的企业,IT将成为企业核心竞争力,甚至每个企业都是一个 IT 企业。类似的概念有金融科技(FinTech)、软件驱动企业、API经济,我觉得还是数字化描述得比较本质,大云物移/SMAC这些提法就技术化了。

企业数字化,我们近些年遇到了很多类似的案例,这里不一一展开,但需要说明的是,这些都是通常意义上的传统企业,他们比以往更有动力做数字化的商业模式。

数字化对 IT 的要求,来自从对内服务为主,增加了对外服务的模式,以云计算的模式,直接面向最终客户和合作伙伴,由于服务对象、业务范围发生了很大变化,需要采用不同的架构实现。

微服务是实现对外服务所必要的,原因有三:1、核心来自对外服务往往与互联网企业竞争,需要更快的速度;2、这些服务往往不是企业当前擅长的,要快速试错;3、业务的压力服务预计,需要架构的弹性。例如我们一个农村商业银行的客户,做了一个农产品买卖的电子商务平台,电子商务业务是他们不擅长的,而直接竞争对手就包括目前的互联网企业,迫使我们必须学习互联网企业的经验。

在数字化过程中,我们实施的案例往往采用混合的架构,新事新办法、老事老办法做过渡,而新事一般采用微服务架构。

上图是一个微服务架构的全景图,注意右上角用 ESB 与传统系统连接。说个题外话,最近很多次交流,大家都提到嵌入式的集成与 ESB 集成模式的关系,应该如何选择,我认为两种都需要,前者对同质系统、自研系统比较合适,而后者用于异构的集成,例如我外购了一个产品,无法把集成的逻辑嵌入到该产品中,只能通过 ESB 进行连通。

我们在实施微服务架构,支撑企业数字化的过程中,遇到了很多挑战,主要来自技术欠债太多、隐形成本过高、知识缺少共享与协作等等。

遇到的问题太多,就事论事的解决问题肯定是不行的,我们在实施过程中从技术的精益运营入手,把技术当作一个Business(这个在此翻译成商业、生意最恰当,而不是业务)来做,从架构、治理、协作等各个方面设立了若干专题,在这些专题中通过技术手段提高效率、降低成本。

其实,云计算的本质是提高效率,而不是降低成本,公有云就是要提高社会的效率,私有云就是要提高 IT 的效率。从这个角度看,实施云计算就是做精益运营,而微服务架构为精益运营提供了架构上的保证,因为微服务是小的、容易变化的、容易控制的。

下面,我主要从架构高可用、提升协作效率和提升治理效率三方面谈一下经验。

介绍一下技术欠债,我们以前基于 OpenSatck + CloudFoundry 做基础架构,当年和银联的同事一起,基于 OpenStack 管理了上千台的物理机。

那时,我们花了很大精力在如何实现高可用,做横向、纵向伸缩,但还是有些不足,例如由于虚拟机启动较慢,导致切换的时候时间窗口太长,为了缩短时间就设置了一些已经启动好的虚机,应用也做成了彻底的无状态,例如 JVM 等使用了共享方式,而不是多份 copy,减少镜像的大小,但总体上资源利用率是有待提高的。

再如高可用的实现中,OpenSatck 实现起来就要引用很多组件,能实现,但是比较复杂。

通过 OpenStack 和 CloudFoundry 的实践,我们发现,他们是为了管理而生的,架构的核心是为了更灵活的管理各种设备,而不是为了高可用,类似的还有虚拟机技术,也是为了更方便管理的目的。

基于这样的思考,我们决定把 OpenStack 做薄,让他做最擅长的虚机管理,而高可用等能力交给 Kubernetes,因为在架构上后者天生为调度而设计。

至于为什么选择 Kubernetes,先前微课堂讲师宋潇男已经做了介绍,大家可以在 EAII 公众号(微信号:eaworld)下载相关PPT。

我们用 DevOps 提高协作的效率,加快开发、测试、部署的效率,首先是将应用代码与基础设施分离,开发工程师提供应用的代码、配置、环境信息、安装介质、实现后的软件资源(例如对外接口、数据库表),通过 DevOps 平台进行自动化的部署。

上图为微服务 DevOps 的概念模型,内容有点多,就不一一解释了。

由于在 DevOps 过程中有很多的工具,协作就是要把这些工具打通,协作起来,例如需求是用 Jira 管理的,在 DevOps 平台注册用户后,就可以在 Jira 里面自动注册。

我们做了很多看板,让需求、设计、运维、测试不同角色的人员,通过看板能够了解其他环节的工作,而看板的数据来自于被集成系统,例如在 Jira 里面编辑需求的时候,会自动推送到 DevOps 的看板上。

集成 DevOps 领域工具链,是基于概念模型,结合 AAAA 完成的,这里面工作量比较大,而且上述工具链的审计我们还没有实现,比较复杂。

同时,我们的 DevOps 平台准备基于Kubernetes 实现微服务新版本发布、金丝雀测试、预发和滚动更新,这也是一个基于 OpenStack 比较复杂的工作,用 Kubernetes 的标签概念就比较简单。目前正在考虑通过数据服务解决服务发布的数据库蓝绿部署问题,帮助微服务做好发布、回滚、灰度发布。

面向互联网应用的微服务架构,是一个分布式架构,比较复杂,因此必须提高治理的效率,我们是用元数据来完成的,这是一个元数据在微服务架构中应用的例子。

有了微服务的元数据,就可以做很多事情,上图是通过元数据做各阶段版本的比较。我们曾经在某特大型城市商业银行,利用元数据从设计工具(PowerDesiner)、预发环境、生产环境采集软件资源信息(例如数据库),预发环境、生产环境进行比对,列出不一致的地方,再参考设计,人工确认无误的情况下,才发起生产上线流程。

还有在云中的自适应安全,都可以基于元数据来实现,普元首席架构师顾伟在 CSDN云计算大会的分享中,也会讲到这一点。

元数据的话题,在微课堂也已讲过两次,包括应用场景和技术实现,大家可以关注 EAII 公众号(微信号:eaworld)。

总结一下今天的内容:我们在这些年的实践中,用微服务架构支撑企业的数字化,采用的技术从 OpenStack + CloudFoundry 等管理为主,逐步过渡到 Kubernetes + OpenStack 的模式,同时利用元数据技术提高微服务架构的治理效率,用 DevOps 提高协作的效率。

在精益运营的方面有很多功课我们要做,包括今天的内容,我们会逐步分专题细化共享出来,谢谢大家!

时间: 2024-08-29 07:20:41

面向微服务的企业云计算架构转型的相关文章

从 SOA 到微服务,企业分布式应用架构在云原生时代如何重塑?

作者 | 易立 阿里云资深技术专家 导读:从十余年前的各种分布式系统研发到现在的容器云,从支撑原有业务到孵化各个新业务,企业的发展离不开统一的.与时俱进的技术架构.本篇文章从企业分布式应用架构层面介绍了云原生计算架构带来的变化,希望能够帮助更多企业的 IT 转型,利用云计算技术推动其成为市场竞争中的敏捷力量. 进入 21 世纪以来,我们见证了企业分布式应用架构从 SOA(Service-oriented Architecture),到微服务架构,再到云原生应用架构的演化. 为了说明企业架构演化背

基于微服务的企业应用架构设计范式

这个话题曾经分别在PWorld大会和QCon2016大会上做过分享,得到不错的反响,因此借着今天这个机会也分享给大家. 微服务好像是这两年突然火起来的,其实和很多其他架构风格一样,微服务架构也是我们在用软件改变世界的过程中,为了适应内外部环境的变化,而逐渐演化出的一种当前的最佳实践. 比如SOA,比如J2EE,比如传统分布式:微服务架构和它们都有千丝万缕的联系. 范式一.采用同步方式记录业务流水 流水记录了业务状态最终确定前的整个过程,是给业务参与各方看的,这个参与各方包括了客户(比如大家拿到的

【转】从SOA到微服务,企业分布式应用架构在云原生时代如何重塑

摘要: SOA 采用中心化的服务总线架构,解耦了业务逻辑和服务治理逻辑:微服务架构回归了去中心化的点对点调用方式,在提升敏捷性和可伸缩性的同时,也牺牲了业务逻辑和服务治理逻辑解耦所带来的灵活性. 为了解决上述挑战,社区提出了 Service Mesh(服务网格)架构.它重新将服务治理能力下沉到基础设施,在服务的消费者和提供者两侧以独立进程的方式部署. 这样既达到了去中心化的目的,保障了系统的可伸缩性:也实现了服务治理和业务逻辑的解耦,二者可以独立演进不相互干扰,提升了整体架构演进的灵活性.同时服

解析微服务架构(二):融入微服务的企业集成架构

上一篇文章介绍了微服务架构的起源.定义.通用特性.常见概念误区.微服务架构与SOA架构比较.微服务架构收益以及企业引入微服务架构的策略. 本文将介绍融入微服务的企业集成架构的演进,并描述交互式系统的微服务模式及相关技术决策,然后给出了一个具体的微服务架构业务应用的例子. 交互型系统(System of Engagement)与记录型系统(System of Record) 随着移动互联网的快速发展,企业除了需要提供传统核心IT系统能力之外,还需提供客户与合作伙伴友好型的以交互为重点的创新及交互式

企业IT架构转型之道 读后感

放假三天,用部分时间阅读了企业IT架构转型之道这本书.第一遍潦草读完,就感觉收益颇多.这本书值得多读几遍,适合精度. 作为银行IT开发人员,在央企IT成本部门的大背景下,开发过程中遇到的诸多疑惑.困惑逐渐累积在心头,如同路口电线杆上的线缆,日益纠缠,难以厘清.但这些困惑从来没有在脑海里面消失,一旦遇到闲暇的时间就会冒出来. 读完转型之道这本书,不禁感叹阿里巴巴的强大.阿里在高速发展的10年里面,围绕解决其核心业务,在技术上积累的解决方案.方法论令人惊叹. 银行,尤其是中国的几家大银行,如今面临的

面向微服务的体系结构评审中需要问的三个问题-咖啡杂谈:Java、新闻、故事和观点

面向微服务的体系结构如今风靡全球.这是因为更快的部署节奏和更低的成本是面向微服务的体系结构的基本承诺. 然而,对于大多数试水的公司来说,开发活动更多的是将现有的单块应用程序转换为面向微服务的体系结构,这可能是许多层面上阻碍和冲突的根源. 虽然Greenfield (未开发的)面向微服务的体系结构实现可以坚持对当前微服务的严格解释-设计原则.但在面向微服务的体系结构中,分解的遗留应用程序存在灰色阴影,如果没有其他原因,只能满足预算和时间限制. 在企业管理链的某个地方,有一位业务主管在一个面向微服务

杂谈:面向微服务的体系结构评审中需要问的三个问题

面向微服务的体系结构如今风靡全球.这是因为更快的部署节奏和更低的成本是面向微服务的体系结构的基本承诺. 然而,对于大多数试水的公司来说,开发活动更多的是将现有的单块应用程序转换为面向微服务的体系结构,这可能是许多层面上阻碍和冲突的根源. 虽然Greenfield (未开发的)面向微服务的体系结构实现可以坚持对当前微服务的严格解释-设计原则.但在面向微服务的体系结构中,分解的遗留应用程序存在灰色阴影,如果没有其他原因,只能满足预算和时间限制. 在企业管理链的某个地方,有一位业务主管在一个面向微服务

微服务框架的存储架构

web应用从单点向高并发架构演变时往往遇到最大的问题就是数据库的分布式存储.因为web应用本身就可以集群部署,但其所使用的数据库确是单点的.如果一个web应用开始的时候没有考虑数据库的分布式架构,那么等到要进行数据库集群改造时会发现困难重重,此时通常的做法是将原系统拆分成多个子系统,然后每个子系统访问一个数据库,这几乎重写了整个系统(如果这还不能满足需求,大型企业接下来会增加数据存储总线).很多厂商都是这么做的,包括淘宝.如果你开始你能够考虑到数据库集群,并且这种集群的设置并不增加开发工作量和难

微服务和企业服务总线

在过去SOA中服务是一种粗粒度的服务,也就是与微服务相反,粗粒度的服务有两个好处:易于重用,减轻ESB的负载:而微服务催生,比如对事件总线的性能和可靠性要求提高,因为每个微服务是很小的组件,甚至是一个类,微服务之间的通讯几近类似于两个单个对象之间交互调用,性能称为至关重要,而过去的ESB产品主要面向工作流程的编排与灵活性上,性能是第二位的. 另外,微服务对团队组织也产生不同于ESB时代的影响,ESB时代,很多集成业务逻辑,也就是跨服务调用的逻辑放在ESB中,形成了专门的ESB产品开发团队,这是以