博云技术社区

博云技术社区 查看完整档案

苏州编辑  |  填写毕业院校BoCloud博云  |  官方技术号 编辑 www.bocloud.com.cn 编辑
编辑

博云技术社区由BoCloud博云研究院运营,定期分享ServiceMesh、Serverless、服务网关、kubernetes、容器等云原生技术干货和落地实践。
官方微信:博云技术社区(bocloudresearch)
博云微信:博云(beyondcent)

个人动态

博云技术社区 发布了文章 · 2月27日

观点 | 破解云管理平台在数据中心管理体系中定位模糊的困局

作为多云管理 CMP 领域的实践者,博云的云管理平台产品(一体化云管平台BeyondCMP)已经发展多年。近两年我们发现很多企业客户对于云管理平台在企业数据中心管理体系中的定位是很模糊的,尤其是以下一些问题,在行业内也一直没有达成共识:

  1. 云管理平台与数据中心中已有或准备建设的各类管理类平台系统的关系是什么?比如 ITSM、CMDB、自动化平台、容器管理平台、监控平台等。
  2. 云管理平台中有个很重要的概念叫做“纳管”,那云管理平台的纳管对象应该包括哪些
  3. 服务目录是云管理平台中非常重要的概念,通过服务目录,云管理平台实现各类资源的自助化、自动化申请,对外扮演着数据中心对外服务的重要角色。那么云管理平台的服务目录与 ITSM 的服务目录又是什么关系?

本文针对以上问题,结合这些年博云的云管理平台在企业落地实践中的经验和我们对行业的观察,提出一些自己的看法和理解,一家之言,仅供大家参考。

01

我们先看看现在数据中心的被管理对象和管理平台都有什么。总结下数据中心中的被管理对象,如下图所示:

image

上面这个图大体覆盖了目前数据中心的被管理对象(没有包含大数据组件,大数据类组件目前在云管理平台项目中涉及的非常少,独立性也很强,不纳入本文讨论范围)。可以看到数据中心中的管理对象是非常多的,还存在各种异构的情况,比如计算资源就可能涉及小机、X86、国产化服务器等,存储和网络涉及的品牌型号类型就更多了。

为了管理如上的这些对象,各个企业可能已经在数据中心体系下建设或者准备建设各种各样的平台,大体包括如下图中的这些平台、系统、工具:

image

分层对应各个管理对象和管理平台/工具和个人的一些观点认识:

基础设施层

针对各类基础设施的管理工具,目前最普遍建设的对基础设施的监控。对基础设施的各种自动化能力建设,比如基础设施网络自动化、存储提供自动化等,只有少部分企业做了建设。

IaaS层

对各类私有云、公有云中 IaaS 虚拟化资源的纳管和监控,这部分目前是云管理平台管理能力的主战场。

容器云平台

容器云比较特殊,可以认为是卡在 IaaS 和 PaaS 中间的一个平台。容器云的管理上,目前行业里一般都由容器云平台提供商提供容器云管理平台,同时一般容器云还提供了基于容器的应用发布管理平台。

数据库层

现在数据中心中的数据库越来越多,包括大量的开源数据库已经使用了起来,所以专业的数据库管理平台需求也越来越多,行业里开始规模落地。

中间件层

中间件这一层,在目前数据中心中的位置是比较模糊的。首先是大量的中间件已经在使用,但是这些中间件的管理要由哪个部门、哪些人负责,行业里相对还没有共识。有的企业是安排了专人负责;有的则没人负责,直接依赖于应用提供商,但通常情况下,应用提供商通常也仅仅是中间件的使用方,而不是中间件专家,所以就带来了各种问题。个人认为中间件这一层在数据中心中应该是专人负责、统一提供和管控的。否则大量各种不同类型/版本的中间件在数据中心中的大规模使用,最终可能会成为一种管理灾难。

应用层

实际上企业所有的运维活动,本质目标都是希望应用能正常、稳定的运行和提供服务,所以应用的运维管理是非常重要的。这一层涉及到的平台工具包括应用自动部署发布、应用监控告警、微服务治理、日志监控等。

各类跨层次的工具平台

包括跨层次的自动化场景(典型的有容灾切换、自动巡检等)、数据中心的运营管理、统一监控平台等。还有一些跨层次的底层工具:自动化作业、配置管理 CMDB等。

服务目录

目前企业里一般包含传统 ITSM 的服务目录和云管理平台的服务目录两类。

02

基于以上信息,我们对目前行业中云管理平台定位模糊的问题的认识得出以下结论:通过长期观察,我们发现云管理平台在行业中之所以出现定位模糊的问题,核心原因是搞混了管理功能(对各层次资源的管理、监控等)和服务提供功能(服务目录)。

问题1:因为云管理平台要提供某类 “ 服务目录 ” ,所以云管就需要把这些服务目录涉及的资源 “ 纳管 ” 了?

具体落地来问:云管理平台要把如下这些资源全部管理起来吗?这合理吗?能实现吗?

image

细想并不难理解,通过云管理平台将如上资源的管理监控一起来做,是不合理的,也是不现实的。

典型情况:各种异构传统存储资源的类型是非常多的,行业内几乎没有什么成熟产品可以做管理整合;数据库是一个专业领域,有很多专业厂商专门做,做的也很好,应该由专业厂商来做更合适;各个企业都已经有了自动化平台,自动化作业的专业能力也应该由专业厂商来提供更合适;应用管理、监控、容器云管理、中间件管理、CMDB 等都是类似的情况。

所以对云管纳管范围这个问题,我们认为:由云管理平台一个单平台来 “ 纳管一切 ”,是不合理的,也是很难做好的。对数据中心中各层对象的管理包括专业工具提供,应该由各个专业管理平台工具来做。

当然,IaaS 层的各类异构虚拟化资源,是云管理平台天然的管理范围,由云管理平台来做管理,是合理的。

问题2:ITSM 的服务目录和云管的服务目录是什么关系?需要怎么处理?

传统的 ITSM 的服务目录,实际落地下来,是线下手工交付模式,存在效率低、响应慢、管理不方便、体验不好等问题。云管理平台的服务目录利用自助线上申请审批、资源整合自动化交付的方式,解决了云资源交付的效率和体验问题。但是部分 ITSM 大量的手动服务的服务目录还是要保留的,因此这两块应该是整合关系。

所以对 ITSM 服务目录和云管服务目录关系这个问题,我们认为:云管理平台的服务目录和 ITSM 的服务目录应该做整合。

而云管理平台的纳管对象和云管理平台的服务目录,应该是分离的。服务目录的对接对象,应该包括底层的各个独立管理平台。

3

以上是我们目前对云管理平台在数据中心中定位的观察和观点,总结一下:

  1. 数据中心中各层对象的管理包括专业工具提供,应该由各个专业管理平台工具来做。
  2. 云管理平台的管理对象应该主要集中在 IaaS 层的各类异构虚拟化资源。
  3. 云管理平台的服务目录与 ITSM 的服务目录做整合,服务目录是云管理平台的核心重要模块。

综上所述,服务目录统一建设,各类资源的管理让专业的来,正是解决云管管理平台在数据中心中定位模糊问题的最优解决方法。

查看原文

赞 0 收藏 0 评论 0

博云技术社区 发布了文章 · 1月29日

农商行数字化转型的烦恼

IT技术日益革新。当我们在给客户分享烟囱式的单体应用如何逐步拆分演变为SOA架构,SOA架构再如何彻底拆分演变成微服务架构的时候,更为新型的技术、架构又在冲击着我们的认知。

互联网行业就像技术赛道上的领跑员,拖着很多老旧应用系统的企业,如资源、金融、交通、银行等行业,也不得不努力跟一下技术的脚步。然而,从哪里起步、如何转型,成为他们最大的烦恼。

微服务相关的工作我们已经搞第四个年头了,“敏态服务运行支撑”在博云的微服务团队经过了N次实践,踩坑淌雷不计其数。从微服务框架、API网关,到服务网格、XX中台,从开源的到自研的,又将自研的开源出去,这么多项目走下来,我们觉得也该认真地记录和认真地回答一下有关“数字化转型”的问题了。正好结合最近我们博云众多的农商行项目,和大家分享一些技术架构的转型经验。

传说中所谓的“双态IT”

前两年有个流行语叫“双态IT”,是由联想提出的“稳基业、敏突破”和谐共存的发展战略。稳态,通常指因为各种原因无法微服务改造的系统,或单体的或SOA架构的;敏态,自然是指可以微服务架构改造的,也就是我们做项目的主要价值范围。所谓双态和谐共存,其实就是指我们要建设的敏态系统如何与未改造的稳态系统实现互联互通。这其实是企业数字化转型工作中的重点和难点。

敏态:敏到什么程度

数字化转型项目的核心自然是技术架构的设计。新型的技术架构无外乎容器、微服务等云原生技术。因此,使用微服务的理念,敏捷开发搭载容器技术的快速集成与持续发布,这样的架构就是我们的预期——敏态。

当然,技术架构的设计作为整个项目的核心,必须要仔细研究,诸如架构选型、组件选型、开发规范、日志规范等等。后面有机会我们会再单独写一篇文章来分析具体技术架构的设计,在今天这篇文章里,我们只谈关键目标,只谈企业数字化转型中的整体策略。

微服务的技术应该是早于容器技术的,但是当容器技术走上舞台的时候,大家才发现这样的理念正是微服务最好的载体,因此微服务也跟着火了起来。这导致有很多未接触微服务的人,以为容器和微服务是有“因果关系”的,但实际上并非如此。

其实现在很多开源的微服务技术SpringCloud、Dubbo等与容器调度Kubernetes,多多少少是有点重叠,甚至冲突的,问题主要体现在服务注册发现、网络通信和负载均衡等等。当然,相应的解决方案还是容易找到的,比如舍弃etcd的服务发现,使用微服务注册中心组件,使用underlay网络方式等,还是能找到融合点的。

总的来说,敏态“敏”到什么程度?第一,服务逐步迁入容器中,节省资源、便于调度管理(有这两点好处就够了);第二,业务系统逐步改造成微服务,拍定一个未来五年内的微服务架构规范,在合适的机会改造每个业务系统

那么问题来了,需要在业务系统改造成微服务的同时,将业务系统运行在容器平台中吗?经过我们多个项目的经验发现,在项目未启动的时候,这几乎是不言而喻的,但是在项目进行中却往往都是妥协的。因为容器改造和微服务改造大多数情况是在不同项目中启动,容器项目一般由运维部门推动,而微服务项目往往由架构部门推动,在项目时间紧张、各有难点并想突出收益的情况下,这样的对接有点貌合神离。

但这其实也没有关系,数字化转型不只是需要技术架构的转型,更重要的是技术理念的转型,包括运维方式、管理方式、研发模式、团队运行模式等等。所以这需要企业做好“不能一步到位”的心里准备,逐步学习、逐步遇到问题解决问题,才能更好地走好转型之路。

稳态:稳如绊脚石

微服务转型过程中,最大的绊脚石就是那些非微服务的系统,项目中通常叫做老旧系统。而这些系统往往是银行内的核心系统或关键系统。

技术架构的转型,不能影响现有业务,这是转型最大的原则和底线,所以这些在银行内业务上承担极重角色的老旧系统,在技术架构上要以稳态保留。我们做微服务治理,希望、也假设全都是微服务,接入、规范、治理、检测、展示,然后大功告成。但我们在做微服务改造的项目时,微服务治理这些只是基础,新老系统间的通信才是重点

技术纷繁复杂,管理往往都在趋向统一。尤其是做数字化转型的时候,开发框架、运行方式、通信协议全部都要统一。为了建设更宏伟的目标,我们首先应该让通信协议统一,在协议没打通的时候,自然就应该做好协议转换工作了。敏态系统多数是七层的协议,HTTP、RPC类的,报文往往是JSON格式,但特点是比较统一,基本上已经被微服务框架所决定了;稳态系统的协议就复杂了,有很多都是独有的协议,报文格式也不同。

复杂是比较复杂的,场景变化也是比较多的,但场景和规划搞清楚了以后倒也不是特别难。原因有两点,一个是我们只考虑敏态与稳态间的通信,其实这是属于通信不频繁的,因此性能要求不会特别高,当然如果有性能要求高的我们要在规划上尽量规避;第二个是我们只考虑实际通信的具体几个接口,逐个做协议的翻译工作,平均每个接口半天时间就翻译好了。那么翻译工作在哪儿做呢,脏活累活扔给API网关。

API网关-数字化转型的负重者

不只是在数字化转型的项目中,在很多新型架构中都有API网关的用武之地。当然我要说一说服务网格,Sidecar其实就是个API网关,例如在Istio的解决方案中使用envoy。那在此处,API网关至少需要担任三种角色了:

  • 敏态架构中,应用聚合对外提供服务,需要用到微服务网关,这是最简单的一个网关了,做简单点只要支持配置路由就可以了;做复杂点也可以加一些治理、使用、权限、审批等等。
  • ESB的统一对外接口,ESB(或者SOA架构中的别的服务总线)本身就很类似于一种网关,将所有其他系统的不同协议整合、转换、通信。但是从服务总线出来的通常是TCP协议,总之不是微服务框架舒服的协议。所以还是需要再转一下,转成敏态系统可以随意访问使用的协议。这就是API网关的第二种角色,用来对接ESB这类的服务总线。
  • 还有一种独立的业务系统,既没被服务总线接管,也没做微服务化改造,但就是想要注册到注册中心,以微服务的通信方式与微服务互访。以前极力不赞成使用Sidecar将老旧系统接入微服务框架中做治理,但是我们在项目中发现,企业也的确是有这样的需求,好在方案也简单。所谓Sidecar就是API网关,依然是做好协议、报文的转换,然后将其以业务服务的方式注册到注册中心。如此一来,之后对该业务系统做了改造,倒是可以更好对接之前的微服务了。

所以项目的重点和难点其实是在API网关的建设,为什么说是重点呢?技术架构做的是规范,服务治理做的是运行中的观测,而网关是运行中业务通信的桥梁,直接影响到业务的访问。

总结一下,多数金融、证券、中小银行都已经处在做数字化转型的关键阶段了,而转型的真正价值其实在于规范管理和理念学习。这个世界变化太快,等需要的时候再学习就太晚了,现在转型还是尽量把心态放在学习和适应上。那么转型中的关键:新型技术的选型、改造的范围、存量的兼容,在这篇文章里我们都做了简单的介绍,希望能给即将做数字化转型的企业或者正在做数字化转型项目的企业提供一些思路,减少一些忧虑。后续如果有机会,我们会对微服务技术架构每一块都做更深入的探讨。

查看原文

赞 0 收藏 0 评论 0

博云技术社区 发布了文章 · 2020-12-04

Kubernetes弃用Docker?其实不用慌

近日,Kubernetes 在1.20版本中 的 ChangeLog 提到,将废弃 Docker 作为容器运行时。

kubelet 中的 Docker 支持功能现已弃用,并将在之后的版本中被删除。Kubelet 之前使用的是一个名为 dockershim 的模块,用以实现对 Docker 的 CRI 支持。但 Kubernetes 社区发现了与之相关的维护问题,因此建议大家考虑使用包含 CRI 完整实现的可用容器运行时。

虽然这一问题在行业内引起了关注与讨论,但其实用户并不需要感到太惊慌。具体可以参考《(闲聊)听说 K8s 要甩了 Docker 了》这篇文章中的解释,以及CNCF 公众号发布的《不要惊慌:kubernetes 和 Docker 》

kubernetes 真的弃用 docker 了吗?

Kubernetes 1.20 版本提到的不再维护 dockershim 垫片,并逐渐在后续版本中移除该垫片,这意味着在未来的 Kubernetes 环境中,docker 的占比将逐渐下降。简而言之,Docker 作为底层运行时的确正在被弃用,但用户不必惊慌,Docker 生成的镜像将继续在用户的集群中与所有运行时一起工作。

Docker 项目自2013年开源以来,引领了容器技术浪潮,至今仍然是众多容器环境下的首选,与 kubernetes 集成的成熟度高,最为稳定。Docker 技术本身在用户体验、容器构建等多方面的优秀表现,也会在开发环境、镜像构建等方面继续活跃。

其次,Docker 项目在最近几年的进化中,已经拆分成了多个小项目,例如 containerd / runc 等,这些新生项目也会在未来的 kubernetes 环境中继续发光发热。

对已使用k8s+docker的用户是否有影响?

作为为企业用户提供容器云产品与服务的提供商,博云也注意到了这一事件,同时我们也收到部分客户对这一问题的疑虑。

博云基于 kubernetes 自主研发的容器云产品是博云的核心产品之一。因此,博云一直深耕容器云底层核心技术的改进与增强,并积极参与开源社区贡献,对 kubernetes 不断增强的趋势一直持续关注和研究。为使企业客户避免单一技术绑定带来的风险,博云容器云平台已经实现提供除 docker 以外的其他多种容器运行时的支持。

目前,博云容器云平台默认使用 Docker 作为 kubernetes 环境下的容器运行时,但同时也支持任何兼容 CRI 接口的具体实现,例如CRI-O、containerd等,并在实践项目中进行了实际部署,在技术掌控力、落地实践等方面有大量经验。

对于已经使用 kubernetes+docker 的用户来说,这一更改对用户已有系统的运行不会有任何影响。对于正在建设的项目,这一更改也不会对进行中项目建设产生影响,用户可以自愿选择继续使用稳定性已被验证的 kubernetes+docker,或是选择社区推荐的containerd、CRI-O 等新运行时。

博云将为客户提供系统升级服务选项,供客户自愿选择:1. 如果您需要实现已有应用迁移到新运行时,可以考虑利用多集群管理能力,逐渐将应用进行迁移。2. 如果是新环境,您可以在新环境中直接考虑使用博云容器云平台支持的containerd、CRI-O 等新运行时。

如有更多疑问,欢迎您向博云咨询。

查看原文

赞 0 收藏 0 评论 0

博云技术社区 发布了文章 · 2020-11-17

项目管理全新升级,博云DevOps产品 V3.4正式发布

近日,BoCloud博云推出 BeyondDevOps 产品 v3.4 正式版本,该版本提供端到端 DevOps 的最佳实践落地平台,构建从需求到开发、测试、上线的可视化、自动化的研发过程管理和持续反馈度量体系,帮助企业打造标准化、规范化的研发流水线,实现业务稳定高效的持续运营。

新增亮点

1. 项目管理全新升级

工作项支持多达10种灵活可配的自定义字段属性类型,通过自定义属性可以为工作项添加扩展字段,满足个性化界面的需要。

image

2. 工作流全新升级

将工作流从系统模板扩展到项目中,增加项目级工作流,方便项目经理在项目中能够更灵活的配置工作项状态的流转。

image

3. 工作台

支持个人工作台功能,工作台中整合了个人待办事项列表,可以更加专注于工作,提高工作效率。

image

关于BeyondDevOps平台

BeyondDevOps 平台是博云提供从 “ 需求 -> 开发 -> 测试 -> 发布 -> 运维 -> 运营 ” 端到端的开发运营一体化平台解决方案。平台覆盖项目管理、研发管理、运行管理和运营管理的协同服务和研发工具支撑,将线下 IT 生产过程转变为线上高度自动化、可视化的 IT 生产线,提升产品研发效率,快速响应业务需求,保障工作质量,并通过度量分析、风险预判,持续提升 IT 运营能力。

#率先通过信通院 DevOps 评估,核心工具能力达到国内领先水平

10月20日,在2020 云原生产业大会上,中国信通院针对 DevOps 服务能力等行业痛点,在大会上正式公布了研发运营(DevOps)解决方案分级能力要求等多项云原生领域标准评估结果。博云成为首批通过信通院 DevOps 评估的云计算厂商之一。

研发运营(DevOps)解决方案能力分级要求规范了DevOps解决方案应具备的服务能力,覆盖项目管理域、应用开发域、测试域、运维/运营域等应用开发运营全生命周期能力子域。标准对 DevOps 解决方案及相关工具能力进行分级,分为基础级、增强级、先进级

作为率先通过中国信通院首批 DevOps 评估的厂商之一,博云 BeyondDevOps 平台获得 DevOps 应用开发域的最高级别——先进级认证。这意味着 BeyondDevOps 的集成开发环境、代码托管、代码评审、编译构建、流水线、部署发布多项 DevOps 核心工具能力达到国内领先水平

目前,博云 BeyondDevOps 平台在金融等行业已拥有大量案例,能够为客户提供稳定可靠的 IT 交付生产线,帮助企业打造适合自己的研发运营一体化平台,通过实现业务、开发、测试、运维团队的一体化,帮助企业客户业务又快又好地上线发布。

查看原文

赞 0 收藏 0 评论 0

博云技术社区 发布了文章 · 2020-10-28

博云助力奇瑞金融新一代核心系统正式上线

近期,奇瑞徽银汽车金融股份有限公司(以下简称奇瑞金融)宣布旗下汽车金融新一代核心系统成功上线。在这一过程中,博云通过容器云、微服务等 PaaS 产品服务,助力奇瑞金融新一代核心系统建设,打造基于 “ 容器云微服务化 ” 的标杆实践。

作为中国银监会批准的首家自主品牌汽车厂商与本土银行合资成立的汽车金融公司,奇瑞金融始终坚持科技引领未来,积极推动数字化转型进阶,在 IT 架构层面致力构建安全稳定、灵活高效的 IT 系统架构

容器云+微服务化,解决原有系统与业务需求的矛盾

随着业务的快速增长,奇瑞金融原有核心系统与业务需求的矛盾逐渐凸显。原有核心系统的扩展性、稳定性、维护性等方面已经不能满足业务快速变化发展的需求,对于业务需求的响应上越来越受到挑战。

为解决以上问题,奇瑞金融希望新一代核心系统能够:

  • 支持以客户为中心的功能服务体系,快速响应客户需求;
  • 实现灵活多样的业务服务流程编排,支持多样化的金融方案;
  • 构建系统组件化的应用系统架构,实现业务功能快速迭代发布;
  • 完善管理信息化和敏捷化,提升服务管理效率、降低人工运营成本、实现高效业务处理。

通过对众多方案调研评估,奇瑞金融注意到,基于容器云和微服务化的 PaaS 技术,在应对高并发、高吞吐业务场景上具备诸多优势,可提高对业务连续性、可用性的支持,以及可提高基础计算资源利用效率。同时,PaaS 技术的独立、稳定、高可靠、灵活、敏捷等特点,也与奇瑞金融 IT 系统架构转型目标一致。

选择博云,构建以资源虚拟化、应用容器化、服务治理化为特征的新一代架构

对于金融科技而言,IT 系统架构的稳定和可靠是重中之重。这就对产品技术提供商提出了更高的要求:

  • 具备领先的产品技术竞争力,满足奇瑞金融战略发展要求、满足产品应用的广度;
  • 具备丰富成熟的成功案例,产品平台能力经过行业生产级长期验证;
  • 具备良好的开放性与扩展性,便于快速开发新业务、新功能,支持未来不断变化的业务特征;
  • 具备灵活性与无关性,可支持与其他系统集成和较强的跨系统平台能力;
  • 具备雄厚的研发实力与长期服务能力,可以为奇瑞金融提供及时、稳定的产品服务。

经过严格评选,BoCloud博云容器云、微服务、PaaS 平台的产品能力获得了客户的青睐,专业全面的服务能力也得到了客户的信任。根据奇瑞金融新一代核心系统建设需求,博云基于容器云 BeyondContainer 和微服务 BenyondMicroservice 产品,助力奇瑞金融建设以容器为基础,以 DevOps 为理念,面向微服务应用的 PaaS 平台:

  • 基于博云容器云 BeyondContainer 产品,围绕业务应用构建了容器平台。提供镜像仓库、自动部署等服务,为应用开发提供支撑应用运行所需的软件运行时环境,平台提供多层次高可用设计,保证业务安全性和平台稳定性,让开发人员专注于核心业务开发。
  • 基于博云微服务治理 BeyondMicroservice 产品,建设微服务治理体系。围绕服务注册发现、管理、微服务、流控、熔断、负载均衡、分布式调用监控、路由、分布式的配置的框架,提供全套的服务治理、服务生命周期管理等轻量级微服务解决方案。分布式与微服务相结合的高并发应用架构,支持各种量级的并发用户使用。
  • 集成 DevOps 工具,建立需求开发测试敏捷化、运维管理标准化自动化。使平台具备 DevOps 持续集成和持续交付能力,实现业务功能快速迭代发布。

奇瑞金融新一代核心系统是以资源虚拟化、应用容器化、服务治理化为特征的新一代架构,具有高性能、低成本、弹性扩展、敏捷交付等特点,可以支持随时、随地、随人、随需的业务需求,有效解决传统架构的性能瓶颈。同时,容器化、微服务化的架构更易于通过模块化独立提供服务,便于业务应用快速组合和重构,也更易于维护。

新一代核心系统以客户为中心,全面实现业务流程化、产品参数化、系统平台化、数据标准化、核算自动化、交易组件化。奇瑞金融表示,新一代核心业务系统的上线,大大提高了授信管理、产品管理、贷款核算等工作的效率,助力公司更好地服务客户,也整体提升了奇瑞金融的软实力,给企业带来了长远的发展动力。

查看原文

赞 0 收藏 0 评论 0

博云技术社区 发布了文章 · 2020-10-26

云原生热点技术国内使用现状 | 趋势分享

导读

数字经济大潮下传统行业的数字化转型,成为云原生产业发展的强劲驱动力,“新基建”带来的万亿级资本投入,也将在未来几年推动云原生产业的发展迈向新阶段。据云原生产业联盟相关调研数据显示,云原生产业作为现阶段云计算PaaS市场的重要支点,2019年我国云原生产业市场规模已达350.2亿元,未来还将延续高速增长态势。

10月21日,云原生产业联盟于2020云原生产业大会发布了国内首个《中国云原生用户调研报告(2020年)》(以下简称 “报告” ),详细展示了中国用户在云原生应用建设方面的现状和需求,客观反映了容器、微服务等云原生技术的应用和挑战。

中国用户云原生建设现状

01

现阶段已有 9% 的用户云原生相关投入已占总 IT 投入的一半以上,技术研发与运维为主要建设支出方向

报告显示,云原生技术价值在用户侧得到了初步认同,已有部分用户将 IT 建设的重心转移到云原生上,云原生应用建设需求在逐渐增长。然而,新技术的普及推广仍需要时间。同时,调研数据显示,在云原生建设支出中,用户资金投入主要用于技术研发和运维。

02

云原生集群部署状态:多云/混合云架构有望在未来成为主流

报告显示,云原生服务部署形态趋于多元化,多云/混合云架构有望在未来成为主流。74% 的用户已经在使用或未来 1 年计划采用多云/混合云架构,仅 26% 的用户没有使用多云/混合云的计划。

03

用户最担心云原生规模化应用的安全性、可靠性和连续性

调查数据显示,提升架构弹性扩展能力与资源利用率,是用户采用云原生技术的重要驱动因素。通过使用云原生技术,76%的用户提升基础平台资源利用率并节约了成本,63%的用户提升了业务应用弹性伸缩效率和灵活性。但值得注意的是,规模化应用的安全性、可靠性和连续性成为用户选择的主要疑虑。

博云洞察:随着云原生技术的普及推广,预计未来几年,在产业联盟、社区组织、云原生技术厂商等的推动下,云原生技术在用户侧会有更广泛的落地应用。

然而,报告数据显示,由于云原生技术难度较高,在选用云原生技术时,61%的用户对云原生技术在大规模应用时的安全性、可靠性、性能、连续性心存顾虑,如果用户完全依靠自研,或将导致用户建设成本呈现较高增长。

目前,多云/混合云作为目前大多数企业的首选云策略,在降低多个公有云、私有云厂商绑定、业务中断等风险具有巨大优势。然而,多厂商的异构云服务和技术产品也使得企业多云 IT 环境变得更为复杂,如何实现对多云/混合云进行统一纳管、实现多云资源的统一调配管理,成为企业亟需解决的难题。企业级多云管理平台(CMP)市场呈现巨大发展空间。

因此,与专业的云原生技术厂商合作或将成为用户未来实现云原生落地建设最稳健的选择。

中国用户云原生技术应用现状

以容器、微服务等为代表的云原生技术,带来一种全新的方式来构建应用。报告指出,云原生技术实现了应用的敏捷开发,迭代效率和交付速度持续加速,用户应用发布趋于高频。目前,60% 以上的用户已在生产环境中应用容器技术,1000节点规模的容器集群能够满足近 8 成用户的生产需求。作为容器最主要的应用场景,80% 用户已经使用或计划使用微服务。

01

容器:超6成用户在生产环境中应用容器,Docker和Kubernetes仍是主流选择

调查数据显示,60% 以上的用户已在生产环境中应用容器技术,43% 的用户已将容器技术用于核心生产业务。同时,报告指出,容器运行时多元化发展趋势已经显现,但Docker 仍是现阶段最主要的选择,83% 的用户容器运行时技术选用 Docker。此外,Kubernetes 延续在容器编排技术领域的领导地位。

02

微服务:微服务架构趋于主流,80%用户已经使用或计划使用微服务

在本次调研的用户中,50% 的用户已经使用微服务架构进行应用开发。在选型方面,Spring Cloud 是现阶段用户最主要的选择,76% 的用户在微服务框架上选用了 Spring Cloud,19% 的用户选用 Istio 来治理微服务。此外,中国本土开源项目也有相当比例的应用。但值得注意的是,现有平台微服务治理能力不足、缺少应用微服务拆分的标准规范,成为用户应用微服务架构的最大挑战。

博云洞察:云原生理念被认为是云计算发展的必然导向,采用基于云原生理念的技术和方法:以容器为基石,通过微服务化的改造,融合DevOps理念,有助于更好地实现业务“迁于云”或“生于云”,能够帮助企业快速构建更加适合云的敏捷应用服务。

博云基于 kubernetes 自主研发的 BeyondContainer 容器云平台,坚持聚焦平台底层能力的提升。除了提供企业级 kubernetes 集群管理能力之外,博云还可提供更高效的容器网络解决方案、负载均衡能力、胖容器解决方案等容器能力,确保能满足用户 IT 敏捷化的需求。博云也作为国内容器云领域领军企业入选 Gartner 《2020年中国 ICT 技术成熟度曲线报告》,被评为 CaaS 容器云代表性厂商。

针对异构微服务框架的统一服务治理问题,博云推出了BeyondMicroservice 微服务治理平台,提供统一的服务监控和治理,深度关注不同微服务框架运行中的服务治理问题,提供负载均衡、路由控制、访问控制、黑白名单、容错屏蔽等功能。

同时,博云 BeyondDevOps 研发运营一体化平台提供全栈式 DevOps 落地服务,为客户提供稳定可靠的 IT 交付生产线,帮助企业打造适合自己的研发运营一体化平台。

云原生技术落地逐渐成为常态。作为国内领先的云原生 PaaS 厂商,博云云原生产品服务已在金融、能源、制造等多个领域实现生产系统落地。未来,博云将进一步为客户提供更优质的产品服务,帮助客户构建面向云原生应用的新一代 IT 架构,释放 IT 基础架构生产力。

查看原文

赞 0 收藏 0 评论 0

博云技术社区 发布了文章 · 2020-09-14

东方证券企业架构之技术架构转型实践

摘要

微服务架构是近几年受到各行业广泛追捧的技术之一,微服务架构具有轻型化、便捷化、敏捷化等特点,不仅能够适应业务创新和变化的需要,而且易于维护、变更、升级,契合当前证券业务发展的需要。然而向微服务架构转型也面临不少挑战,东方证券通过构建统一的服务治理框架,打造了一个多语言、多协议、可视化、灵活配置的服务管理平台,支持东方证券企业技术架构向以微服务为核心的现代化架构转型。文本将介绍东方证券gRPC-Nebula服务治理框架与星辰服务治理平台的建设成果,并介绍转型过程中的实践经验。

作者 | 东方证券首席架构师 樊建

东方证券服务治理架构师 舒逸

1

引言

近年来,随着证券市场客户和业务量的不断攀升,以及互联网金融的兴起和金融科技的发展,各证券公司都制定了数字化转型的战略目标。为了把握新一轮数字化技术革命浪潮,企业信息系统架构正在不断升级变迁,很多企业内部的传统软件系统都开始向微服务架构转型,通过服务拆分、降低系统耦合性,达到“高内聚、低耦合”,提供更为灵活的服务支撑。

随着研发人员对系统进行解耦和拆分,对大量微服务实例进行有效管控、提升系统运行时的服务质量变得非常困难。在此背景下,东方证券为了顺应互联网+时代的潮流,响应快速更新的业务需求,迫切需要以统一、服务化的思路来进行系统建设,建设服务治理平台,通过分析服务调用关系及拓扑结构、优化服务质量、制定服务协议规范,达到新建系统与已有系统统一服务治理实现轻应用(业务为导向,实现业务应用敏捷构建,及时响应市场需求)、重平台(将数据和核心应用转化成平台服务,成为整个架构的核心)、服务化(构建核心服务网络,简化应用开发与部署)的整体企业技术架构转型目标,实现应用全生命周期管理。

2

微服务架构

1

单体架构

传统信息系统多采用单体架构,单体架构应用把所有的功能都打包在一个独立单元中,并当做一个整体来开发、测试和部署[1]。Java Web应用就是典型的单体架构应用,项目被打包成一个WAR包部署在同一个WEB容器中,其中囊括了数据访问层的DAO对象、业务逻辑层的各模块、表示层呈现的UI等功能。单体架构的优势是开发、调试、部署简单方便,在业务发展初期,信息系统的规模较小,使用传统的单体架构可以有效地支撑业务的发展。然而,随着业务的爆炸性增长,应用系统规模不断增大,单体架构将给业务系统的开发、维护、部署带来巨大的问题。

第一,开发效率持续下降,庞大的代码规模和错综复杂的业务耦合大大增加了研发新功能的难度,开发者不仅要掌握自己负责的模块,还需要了解整个应用系统的逻辑,否则修改代码后可能会引发冲突或其他模块错误;

第二,持续迭代存在障碍,任何一个非核心功能的小修改都需要重新部署整个项目,使得系统运维中与发布相关的风险显著增加;

第三,系统可靠性变差,传统的单体架构将所有的应用都部署在同一个进程中,如果应用中某个接口发生故障,将会影响整个系统正常提供服务的能力,在巨大的瞬间流量冲击下,很容易引发系统雪崩;

第四,扩展性先天不足,单体架构的应用只能在一个维度上进行扩展,但是不同的模块可能有不同的资源需求属性,例如有的功能是计算密集型,有的则是IO密集型,由于它们运行在一个实例中,因此无法对特定模块进行扩展;

第五,技术僵化无法重构,各个业务使用的技术栈不得不与整个应用的技术栈捆绑在一起,很难更新SDK版本或使用新的技术框架。

2

微服务架构

由于单体架构已不能适应现代企业信息系统的需要,近年来微服务架构被广为推崇,并在越来越多的证券公司中得以实践和落地。微服务架构是由传统的单体架构逐渐演化而来[2],将大型单体应用按照业务功能设计拆分成多个能独立运行、职能单一的服务,与其他服务之间通过统一协议进行通讯3。

微服务架构可以很好地解决单体架构下的诸多问题:

第一,将巨大的单体应用拆分成颗粒度更小的服务,服务内逻辑简单、高度内聚,易于开发和维护;第二,各个微服务独立部署,功能修改后可以针对特定部分进行发布,使得各个微服务系统能够持续化部署,加快了迭代的速度;第三,当单个服务系统出现故障时,只需要将出现故障的服务下线修复即可,不会导致整个系统的级联故障;第四,可根据不同微服务系统的访问量和资源需求,动态的实现横向扩展和纵向扩展,这大大的提高系统的利用率;第五,各个研发团队可以根据自己的需求选择编程语言和技术栈,具有更大的灵活性。

虽然微服务架构有着明显的优越性,但是证券公司普遍存在的系统异构化问题也给微服务架构的落地带来了巨大挑战。

1.业务接口标准不统一,管控风险大

券商行业的核心系统由传统供应商组成,以东方证券经纪业务核心系统为例,分别由金仕达、新意、恒生、顶点、同花顺等厂商架构组成,SPX、T2、Rest、WebService等多种类型服务接口存在于东方证券企业内部,多业务协同适配问题突出,服务多样性对同步、异步、流式数据等都提出了技术需求,统一化难度大;缺乏有效的关键业务流量控制技术手段;全局化平台协同与调度困难重重,缺乏全局视角对内部服务进行统一化管理。 2.自研系统上线面临诸多困难 随着金融科技的深入发展,证券行业纷纷开始进行自研核心系统,但因为缺乏统一的开发框架,各业务研发团队在具体开发过程中除了业务分析之外,还需同时会关注非常多的技术细节,如依赖服务接口对接,开发语言技能,灵活可扩展架构支撑,客户服务治理保障,对外服务协议选型,服务故障定位,请求流量控制,服务安全配置,配置管理,流量管控等,自研业务也面临着诸多现实问题。 3.传统网关模式存在不足 传统核心系统基本采用网关模式进行对外服务,由网关进行接入管控,其一般具有身份认证、路由配置、负载均衡等功能,在对类似手机端这样的客户端时,其能起到比较好的作用,但用在核心机房内部服务调用就存在着明显的不足。

  • 采用网关模式,渠道端须自己封装TCP SDK,进行网关切换,所有的流量都会打到单网关节点,网关本身往往会成为瓶颈;
  • 采用网关模式,往往通过部署多个网关节点进行横向扩展,在运维部署上就会增加相当的工作量,也消耗资源;
  • 采用网关模式,相当于多了一路网络跳转,增加网络耗时,在同等部署模式下,降低了系统整体能承受的并发容量,增大系统延时;
  • 采用网关模式,系统内部微服务对外采用网关对外服务,无法发挥出微服务自动注册,自动发现的优势,新增服务往往需要修改网关配置进行发现,整体架构退化成了传统架构模式。

理想情况下,业务人员关心业务梳理和场景定义,开发人员把相关业务转换成服务定义,借助代码生成工具自动化生成接口代码,最后根据业务实现接口内部逻辑。由开发框架和外部工具负责架构扩展性、服务治理、配置管理等一系列非业务相关的功能实现,实现业务和框架的解耦,提高开发效率。

3

东方证券服务治理平台

完善的服务治理方案是微服务架构应用稳定运行的基石,东方证券凭借在服务治理领域的技术沉淀和实践经验,在gRPC框架基础上新增服务治理特性,建设了gRPC-Nebula服务治理框架和星辰服务治理平台,从而实现企业内部及外部服务的统一化管理,构建服务调用关系及拓扑结构,优化改进服务质量,图1展示了东方证券服务治理项目的总体架构。

图1 东方证券服务治理项目总体架构

东方证券服务治理方案主要包括如下几个模块:

1

注册中心

注册中心是一个分布式、高可用的配置维护系统,用于服务的注册和订阅,它存放着所有的服务描述信息以及服务接口信息。在微服务框架系统中,服务和接口的数量非常庞大,同时由于系统的动态调整,服务运行的实例数量也是动态变化的,注册中心通过将服务统一管理起来,可以有效地优化服务消费者对服务提供者的感知和管理,避免硬编码地址信息。

2

服务消费者(客户端)

服务的消费者,通过注册中心交互获取服务注册信息,基于服务注册信息发起对服务端的调用;同时,采集调用端信息发送到数据处理引擎中进行分析处理,为调用链分析提供客户端数据。

3

服务提供者(服务端)

服务的提供者,通过注册中心对外发布服务信息,响应消费者的服务调用请求;同时,响应控制台等发起的配置管理操作,对服务质量、安全策略、数据收集等进行配置管理。

4

信息收集器

独立的部署的服务,收集服务调用过程中在服务提供者和服务消费者产生的服务调用、服务响应、服务异常、服务时间、调用链路、内部队列长度、安全事件等信息,收集后统一发送到数据处理引擎进行处理。

5

数据处理引擎

数据处理引擎,对信息采集器发送过来的信息事件流进行实时分析处理,处理操作包括性能统计、依赖分析、阈值告警、相关聚类、状态跟踪、可用新分析等;同时,数据被存储到性能管理数据库,用于进一步的分析操作。

6

服务治理门户

服务治理门户汇总了服务治理领域的运行数据和管理系统,它是全公司服务治理的综合平台。在服务治理门户,可以查询每个微服务的实例信息、接口信息、服务状态、依赖和被依赖关系、数据统计、服务调用追踪记录等关键信息和数据,展现了企业服务治理生态的全景图。同时服务治理平台支持黑白名单、流量控制、权重配置、主备配置、上下线状态的管理功能,支持调用量、性能、服务质量、可靠性、故障事件等对象的监控告警功能,是管理人员对微服务进行集中式管理的人机接口,也是故障定位与可视化呈现的中控界面。

4

gRPC-Nebula服务治理框架

01

技术方案

东方证券调研了目前比较流行的开源微服务框架,包括阿里巴巴的Dubbo[5]、Facebook的Thirft[6]、Google的gRPC[7]以及从Spring Boot框架发展而来的Spring Cloud项目[8],它们都具有较好的连通性、健壮性、伸缩性和拓展性,但Dubbo和Spring Cloud框架不支持多语言,Dubbo开源社区曾有一段时间不维护更新,最近才重新启动更新。

因为历史原因,证券行业的原有核心系统存在多种语言开发的现状,例如核心交易系统和同花顺网上交易等系统采用C++语言框架开发,账户、产品、资产配置、APP及自研类系统大多采用Java语言框架进行开发,为了解决证券行业天然存在的跨语言场景,最终我们选择以gRPC框架为基础,研发gRPC-Nebula服务治理框架,为业务方提供服务治理整体解决方案。

相比其他几种框架,gRPC有以下优势:

  • 全面的多语言支持,gRPC支持多种语言,包括C、C++、Java、Python、PHP、Node.js、C#、Objective-C、Go、Ruby、Dart等。目前券商网上交易和核心交易系统均是C++架构,而其他自研系统大多是Java和Python架构,gRPC 能有效解决服务的跨语言调用问题;
  • gRPC在Google和广大开源爱好者的大力支持下,目前社区活跃、更新频繁,已在全世界多家大型科技公司内投入生产;
  • gRPC使用Google开源的Protobuf 3.0协议定义接口服务,Protobuf是一种平台无关、语言无关、可扩展且轻便高效的序列化数据结构的协议,广泛应用于网络通信和数据存储,技术人员对Protobuf的熟悉有助于gRPC技术在企业内的推广;
  • gRPC的传输使用HTTP/2标准,支持同步、异步、双向流,支持SSL和自定义鉴权,支持iOS、Android、Windows、Linux等平台,可以简单地实现客户端到后台的多路复用与RPC调用。

相对于原生gRPC框架,gRPC-Nebula服务治理框架引入了ZooKeeper作为注册中心,  如图2所示,融合了服务注册发现、负载均衡、黑白名单、动态分组、集群容错、流量控制等服务治理机制,本章节后面的部分将详细介绍这些服务治理机制的技术方案。

图2 东方证券gRPC-Nebula服务治理框架架构图

我们分别对Dubbo、原生gRPC、gRPC- Nebula框架进行了性能测试,如表1所示,gRPC- Nebula框架的性能仅比Dubbo和原生gRPC框架低1%左右,满足高性能服务框架的需求。

表1 多框架性能测试比较

02

服务注册发现

服务注册发现是服务治理领域最核心的机制,服务提供者在启动时向注册中心注册它提供的服务信息,服务消费者向注册中心获取服务提供者的地址列表,如图3所示。gRPC-Nebula服务治理框架使用ZooKeeper作为注册中心,具有以下特性:

图3 服务注册发现机制

(1)具备高可用性。当注册中心任意一个节点宕机时,服务能够自动切换连接到其它正常的节点上;当注册中心全部宕机时,只影响新服务的发布与已发布服务的下线,不影响服务的正常运行,服务消费者会使用本地缓存的服务地址列表继续调用。

(2)保证数据一致性。所有服务消费者同一时刻从注册中心不同节点获取到的服务地址列表是同一份数据,不能出现读或写数据的不一致。ZooKeeper使用ZAB协议作为其数据一致性的核心算法[10],是具有严格的访问控制的能力的分布式协调服务。

(3)服务变更主动推送。服务消费者只需要在启动时向注册中心拉取一次全量服务地址列表,其后向注册中心订阅相关服务的变更事件,一旦服务地址列表发生变更,注册中心会主动将变更的内容推送给服务消费者,服务消费者即时调整调用的服务地址。

(4)实时感知服务状态。注册中心与服务建立长连接,通过心跳检测机制,能够周期性地检测服务的健康状态,当服务进程意外终止或服务器宕机时,注册中心能够立刻向服务消费者推送服务下线的通知,实现故障隔离。

03

服务路由

在生产环境上,微服务都是多实例部署,服务路由决定了服务消费者如何从服务地址列表中选择服务提供者进行调用。gRPC-Nebula服务治理框架的服务路由以下三大机制构成:

(1)负载均衡机制

gRPC-Nebula服务治理框架支持连接负载均衡和请求负载均衡两种模式,默认连接负载均衡,同时提供了四种负载均衡算法可供选择:随机策略、轮询策略、权重配置优先策略、一致性哈希策略。

  • 随机策略即随机地选择服务提供者进行调用;
  • 轮询策略即遍历服务地址列表,每次调用时依次选择一个服务提供方进行调用;
  • 权重配置优先策略可根据配置文件或管理门户对每个服务节点配置的权重比来选择服务提供者;
  • 一致性哈希策略中,相同参数的网络请求总由同一个服务提供者处理,当某个服务提供者的节点宕机时,系统基于一致性哈希算法来选择其他的节点。

图4  gRPC-Nebula负载均衡配置

(2)黑白名单机制

通过设置服务端实例的黑名单、白名单,可以动态实现请求流程的转移以及服务端实例的访问控制。如果将某IP加入一个服务的黑名单,部署在这个IP上的服务消费者无法从注册中心获取到这个服务的地址列表。

图5  黑白名单设置

(3)权重配置

gRPC-Nebula能够对服务提供者实例设置不同的服务权重,框架根据权重进行流量分发,这样可以达到根据不同的后端资源能力进行动态平衡。

图6  服务权重列表

图7 服务权重设置

(4)动态分组机制

每个微服务实例都有一个分组属性存放在注册中心,分组属性既可以通过配置文件预先设定,也可以通过管理平台动态配置。通过分组一个微服务的集群可以被划分为多个集合,服务消费者可以按优先级调用某几个特定分组的服务,动态分组机制可以灵活实现同机房调用和业务隔离等场景。

服务端配置:

客户端配置:

图8 动态分组配置

  • 机房调用场景,在数据机房安全性越来越得到重视的今天,多机房灾备方案被各类企业广泛使用,但是跨机房调用的高耗时可能造成系统的容量降低。如图8所示,假设所有服务实例均部署在A、B两个异地机房,服务消费者希望优先调用属于同机房的服务提供者,使用IP段定义机房的策略灵活性和扩展性不足,服务分组策略可以有效满足这一需求。例如将机房A的服务提供者定义为a分组,将机房A的服务消费者配置成优先调用a分组的节点,同时机房B的服务也进行类似配置。这样,机房A的服务消费者会优先调用机房A的服务提供者,避免高耗时的跨机房调用,当Server1和Server2全部宕机时,机房A的服务消费者会把请求自动切换到机房B的Server3和Server4上。

图9 机房调用场景

  • 业务隔离场景,业务隔离是避免微服务系统雪崩效应的常用策略,当一个服务提供者被多个消费者调用时,个别消费者的流量激增可能导致整个服务提供者集群超负荷运作,从而影响所有消费者的调用。服务治理平台的服务分组功能可以将服务提供者集群划分为一个个独立集合,消费者只调用特定分组的实例,这样每个消费者的调用相互隔离、互不影响,可以有效保证整个系统的高可用性。如图9所求,后端服务通过设置tc、wmp、matrix分组,可对交易接入、财富销售中心、东方睿等系统分别提供不同服务等级保障,达到业务隔离诉求。

图10 业务隔离场景

04

集群容错

当服务提供者无法正常为消费者提供服务时,如连接被拒绝、请求超时、后台服务异常等,服务框架需要进行集群容错,重新进行路由选择和调用,gRPC-Nebula服务治理框架支持快速失败(Failfast)和失效转移(Failover)两种策略:

快速失败是指如果服务提供者返回异常,消费者不用重试直接报错。这种策略适合一些非核心的服务,可以为重要的核心服务节约宝贵的资源。

失效转移是指当服务调用异常时,重新进行路由选择,查找下一个可用的服务提供者来发起新的调用请求。当调用一个节点连续多次失败或在一段时间内失败率超过限制时,框架认为这个节点当前已不适合再对外提供服务,服务消费者会将其从服务地址列表中剔除,保证一段时间内都不会调用到这个异常节点。这个机制的目的是降低系统对网络抖动的敏感性,不会因为一次偶然的调用失败而调整流量分配,保持服务器负载的稳定性。和服务分组属性一样,连续失败次数和一段时间内失败率的阈值都可以通过配置文件和管理平台配置。

图11  集群容错配置

05

流量控制

历史上券商核心系统事故都是由流量冲击引起的,当网络流量瞬间爆发性增长时,对服务器CPU和IO资源的抢占会造成系统出现瓶颈,服务错误率迅速上升,此时上游或用户的重试行为又进一步加大了网络流量,最终使得服务彻底崩溃且长时间难以恢复,这即是雪崩效应。为了防止雪崩,需要对服务调用过程进行控制,通过一些策略削减流量,保证后台服务接收的请求在可承受的范围内。

gRPC-Nebula服务治理框架通过设置请求数和连接数限制,动态实现对各服务接口的流控管理。请求数限制即当单位时间内请求数过多时,丢弃多余的请求;连接数限制即控制每个IP连接到服务提供者的连接数,在框架内服务间调用通过gRPC的HTTP/2协议保持长连接,当连接数达到阈值时,服务提供者会拒绝建立新连接的请求。

图12 流量控制配置

06

访问保护状态

访问保护状态功能是服务治理平台控制服务端节点上下线的方式,可以用于无损发布和快速摘除故障节点等场景。例如系统上线更新时,服务的关闭或重启会导致一段时间内调用失败率升高,为了避免失败产生,可以通过服务治理平台将待操作实例设置为不可访问,注册中心会通知所有消费者不再调用不可访问节点。待确认服务端实例无调用请求后,运维人员实施更新操作,更新成功后再将实例重新设置为可以访问。更新过程中流量会平滑地从实例移除和返回,不会产生调用失败。

图13 访问保护流程

图14  访问保护设置

07

多注册中心支持

出于安全管控需求,很多企业将网络划分为多个网段,每个网段部署独立的注册中心。GRPC-Nebula框架支持将服务同时注册到多个注册中心,并且可以将自定义的服务端IP端口注册到注册中心,这个特性为了适配多网段间可能存在的IP地址映射或代理的场景。

图15  多注册中心支持

08

主备服务支持

gRPC-Nebula框架支持主备服务,能够对实例设置主服务器和备服务器。当主服务器可用时客户端只能调用主服务器,不调用备服务器;当所有主服务器不可用时,客户端自动切换到备服务器进行服务调用。

图16 主备服务示意图

图17  主备服务设置

09

内外部服务

gRPC-Nebula框架支持同一项目不同类型的grpc服务具有不同的可见性。服务提供者实现的接口可以划分为两类服务,对于内部项目间gRPC调用服务,此类服务并不对外暴露,因此应该避免外部项目可见;对于项目对外提供的gRPC服务则需要允许外部系统可见。

图18  内外部服务

10

原生gRPC框架优化

  • 断线重连指数退避算法支持

当gRPC连接到服务端发生失败时,通常希望不要立即重试(以避免泛滥的网络流量或大量的服务请求),而是做某种形式的指数退避算法。参考链接如下:

https://github.com/grpc/grpc/...

但这种形式往往会造成服务端失败后,客户端不断的退化重连时间,长时间会退化成一个非常大的时间,当服务端重新启动成功后,客户端反而长时间不能连接成功,故此gRPC-Nebula修改了原生框架,客户端可以自行配置最大的重连时间,规避此类风险。

图19 退避算法设置

  • Keepalive心跳

gRPC原生逻辑具备keepalive心跳机制,客户端心跳默认关闭,服务端心跳2小时发送一次,参考链接如下:

https://github.com/grpc/grpc/...

但在实际生产网络环境中,防火墙通常设置为15分钟就会主动断开无请求的TCP连接,证券行业的特点造成了服务请求主要集中在9:15-15:30这个时间段,这样在非交易时间会有大量TCP连接断开,为此我们修改了gRPC框架,使客户端和服务端都可自行配置心跳时间。

图20 客户端心跳设置

图21 服务端心跳设置

5

星辰服务治理平台

建设目标

由于业务的实际需求和技术发展,开发部门和供应商通常会根据需要选择不同的微服务框架,呈现多样化选型。如何管理好这些服务,成为研发和运维部门需要面对的问题。如果可以将这些框架和服务对接到统一的服务治理平台,将可以大大降低协作开发的成本,并提升整体的版本迭代效率,因此东方证券星辰服务治理平台的建设目标包括: 1.通用治理能力:引入中间层设计,兼容多框架的通用治理能力,采用分发器和治理组件协调工作统一多框架通用治理能力,由分发器下发任务至不同的治理组件,由理组件完成平台纳管多框架,完成分发器下发治理任务。 2.平台自服务:平台本身采用微服务架构及容器平台集成,提供更深度的治理功能,提供平台应用生命周期、组件部署管理、灰度、弹性和统一配置支持。

3.多框架兼容的应用管理:兼容基于gRPC、Spring Cloud、Dubbo三种微服务框架,帮助客户快速部署或迁移微服务应用。

4.业务服务架构防腐化:通过服务注册中心对服务强弱依赖进行分析,结合运行时服务调用链关系分析,梳理不合理的依赖和调用路径,优化服务化架构,防止代码腐化。

5.快速故障定界定位:通过服务调用链日志、服务性能KPI数据、服务接口日志、运行日志等,实时汇总和分析,实现故障的自动发现、自动分析和在线条件检索,方便运维人员进行故障诊断。

6.服务微管控:运行态服务治理,包括限流降级、服务迁入迁出、服务超时控制、智能路由、统一配置等,通过一系列细粒度的治理策略,在故障发生时可以多管齐下,在线调整,快速恢复业务。

7.服务生命周期管理:包括服务的上线审批、下线通知,服务的在线升级,以及上线、下线,自动弹性伸缩,资源扩容。

功能模块

星辰服务治理平台包含以下功能模块:

(1)服务治理

星辰服务治理平台支持对gRPC、Spring Cloud、Dubbo三种微服务框架进行管理,如图5所示,支持查询注册中心维护的服务实例信息,支持通过控制台配置注册中心、访问控制、主备、分组、黑白名单、流量控制、熔断等信息。

图22 服务治理功能

图23 服务间调用

(2)服务地图

服务地图将项目与项目、服务与服务之间的调用关系和调用量通过拓扑图的形式进行展示,如图6所示。系统架构师可以从服务地图提炼出全公司的核心系统拓扑图,找出不合理的环形调用链;运维人员可以从服务地图掌握核心系统所依赖的上游系统,并给予核心系统同级别的重点保障。当预期面临流量猛增时,服务地图还可用于流量预估,因为从客户端等入口预估流量最准确,进而可以沿着服务地图下沉计算出各个微服务分摊到的流量,协助后台系统制定扩容预案。

图24 星辰服务治理平台服务地图

(3)链路跟踪

在微服务架构中,一个用户操作涉及到多个微服务的协同才能完成,在业务调用链路上任何一个微服务出现异常或者网络超时,都会导致失败。通过链路跟踪,我们可以很方便的看到每个请求各个环节的耗时以及异常,帮助我们对系统进行优化。星辰的链路跟踪功能基于Google的Dapper论文[11]实现,在系统入口接收用户的请求后,会为用户的请求分配一个TraceID用来唯一标识调用链。TraceID会跟随远程调用消息传递到下游服务,直到整个链路的节点都拥有了TraceID,通过TraceID可以串起这个请求的完整调用链路。

图25  调用链关系

(4)文档中心

文档中心对ProtoBuf格式接口定义文件进行自动解析,提供技术人员查询各服务注释信息与接口定义的功能。我们把文档中心看作是一个服务集市,技术人员在实现一个涉及通用模块或第三方应用的功能前,可以像逛集市一样来文档中心查询接口的详细信息。未来我们还将强化文档中心的交互沟通功能,增加问答与评论功能,打通各服务上下游的交流渠道。

图26  文档中心

(5)统计分析

统计分析模块支持对服务、实例、端点的性能监控,包括响应时间、可用性、吞吐量等;支持数据大屏,全景展示当前所有服务的运行状态;记录用户请求处理时间,分析出被调用服务的性能;记录服务响应时间,并展示响应时间最长的数个服务,即慢服务列表。

图27  平台统计分析

(6)告警中心

告警中心支持基于监控数据的告警规则设置,并以自定义的方式发出告警通知。

图28  告警设置

(7)框架统一纳管

为了更好的支持企业架构转型,也便于各业务方系统内部有更多的微服务框架供选择,晨辰服务治理平台同时对多种微服务框架进行了统一纳管,在支持gRPC服务的基础上,增加了dubbox及Spring Cloud框架。

图29  多框架支持

6

转型实践

数字化转型

多年来,随着东方证券各类业务的持续发展,数百套业务及支撑系统在线运营,各类应用系统间开始呈现复杂的依赖关系,系统运维的复杂度急剧增加。特别是由于以往系统建设主要由各厂商开发等因素的影响,东方证券内部存在大量的异构业务系统,对外暴露的接口也呈现多种形式,各厂商都有各自私有协议,且存在有 SPX、T2、Web Service、REST、TCP 等各类型异构接口,进一步增加了系统开发、运维的难度。基于这些原因,东方证券从公司战略和技术管理上进行了变革。2018年初,公司提出了“数字化转型”的战略目标,并将“增强金融科技应用”列入公司的六大发展战略任务之一,这促使我们以更加积极和开放的心态发展科技。

与此同时,东方证券同步在企业技术架构上制定了大中台战略,这也是公司数字化转型中的三个核心战略之一(另两个为:核心自主研发、重构企业技术架构),旨在通过架构转型为公司科技工作的长远发展打下坚实基础。为了推进架构转型工作,2019年初,东方证券成立了以首席信息官舒宏总担任主任的架构委员会,旨在通过架构委员会重点进行企业架构转型的工作,同时创建了金融科技创新研究院,以整合东方证券及子公司的技术资源、倡导以研究为主导的技术应用为主要任务。核心自主研发战略的确立,不仅彰显了东方证券对自身技术实力的信心,同时也展现出在实现信息技术自主、安全、可控方面的胆识与魄力。

架构标准

为了建设各业务方遵循标准进行开发的能力,让企业架构建设有据可依,东方证券架构委员会制定了架构标准的决策流程及机制,通过架构标准去约束各系统相应开发实践,2019年5月,我们通过服务治理平台接入规范的架构标准,确定了企业技术架构转型的核心框架,各系统采用统一的接口调用方式,要求系统间调用必须使用gRPC提供服务,系统内部可以采用gRPC/dubbo/Spring Cloud三种框架,支持东方证券 IT 技术架构从传统架构向微服务为核心的现代化面向服务架构全面转型。

图30  服务治理架构决策

大中台战略

为了实现数字化转型,东方证券制定了三年架构规划,通过架构规划及落地实施,打造行业领先的IT架构和一流的IT队伍,形成公司科技发展的竞争力,架构规划中有七大重点任务,其中一项是建设强大的业务共享中台,提炼核心业务流程,为前端产品线提供业务共享能力,给前台提供强大的“炮火支援”能力,确保“厚中台,薄应用”的成功落地。

按照证券行业的领域特点,我们将整个中台领域划分为产品、账户、财富、交易、资产、行情、资讯、日志、认证等中心,而服务治理框架也成为了整个业务中台的核心基础设施。

图31  东方证券大中台战略

开源共享/行业标准

东方证券gRPC-Nebula[9],本身就是在站在开源gRPC的巨人肩膀之上发展而来,为了更好的反馈社区,2019年6月中旬,东方证券宣布开源gRPC-Nebula服务治理框架,开源地址:https://github.com/grpc-nebula,目前社区已建设了社区决策委员会,初期拟设7名委员,含1名委员会主席,设有专人进行GitHub代码的跟踪、维护、解决。

同时,委员会会定期组织研讨和常态化沟通、社区技术交流、协调开发力量进行社区开发、社区筹款、审议版本maintainer的版本和功能集、进行社区委员会选举等工作。社区将秉持金融科技创新,对外技术输出的原则,致力于成为行业内首家基于gRPC可治理RPC框架下的开源社区,并获得了2019年信通院OSCAR尖峰开源技术创新奖(基于社区开源二次开发)及第四届中国优秀云计算开源案例一等奖。

整个证券行业长期以来在技术架构领域没有统一标准,各家厂商都有自己相应的技术框架,从而造成了整个行业一直面对的异构化难题,gRPC-Nebula开源也旨在为整个行业提供参考建议,同时,我们也积极加入了深交所技术产品联盟,推广gRPC-Nebula在行业内的使用,希望能达成行业共识,形成统一技术标准,大幅降低行业各系统间对接成本。

实践成果

从2019年初开始,东方证券进行服务治理框架研发工作,截止2020.9月,gRPC-Nebula框架Java语言共迭代14个版本,C++语言共迭代8个版本,平台迭代了4个版本,较好的支撑了业务各类的需求。

同时,东方证券在内部大力推广服务治理框架及平台的使用,截止2020.9月,共接入各类应用46个,项目99个,服务数369个,方法数3125个,日承载各类请求量已达到数千万级。

从系统维度来看,东方证券服务治理框架已接入内部东方赢家APP、私行APP、通达信网上交易、同花顺机构版、东方睿、东方大脑、智能投顾、大营运平台、业务中台(财富、交易、产品、账户、资产、行情、资讯等)、资产配置等核心系统,从厂商维度来看,微软、恒生、金仕达、新意、顶点、通达信、同花顺等核心厂商及自研团队也已按照架构标准接入服务治理框架及平台,实践成果非常明显。

图32 服务治理平台实践成果

总结

本文探讨了企业架构领域的关键技术,并详细介绍了东方证券服务治理项目的建设成果与实践经验。东方证券在企业架构层面制定了大中台战略,旨在通过业务架构转型为公司科技工作的长远发展打下坚实基础。

作为大中台战略的核心组成部分,服务治理项目的建设,是公司提高金融科技核心竞争力的重要突破。gRPC-Nebula框架和星辰服务治理平台已经应用于东方证券业务中台(财富中心、交易中心、账户中心、产品中心等)、东方赢家APP、私行APP和东方睿机构交易产品线等数十个项目,同时实现了各微服务框架(gRPC-Nebula/dubbox/Spring Cloud)的统一纳管,为业务线开发提供了更多的开发框架选择,随着平台生态的不断优化和发展,未来将在内部全面推广,服务于更多产品线和用户,为公司IT治理规范和体系化架构建设做出更多贡献。

参考文献

[1]Fowler M, Lewis J. Microservices. Viittattu, 2014, 28: 2015

[2]Fotis Aisopos, Konstantinos Tserpes, Theodora Varvarigou. Resource management in software as a service using the knapsack problem model.  International Journal of Production Economics. 2013 (2)

[3]Thones J. Microservices. Software IEEE, 2015, 32(1): 116-116

[4]李贞昊. 微服务架构的发展与影响分析. 信息系统工程, 2017(1): 154-155

[5]https://dubbo.io/

[6]https://thrift.apache.org

[7]https://grpc.io/

[8]https://spring.io/projects/sp...

[9]https://github.com/grpc-nebula

[10]Hunt P,Konar M,Junqueira F P, et a1. ZooKeeper:Wait-free Coordination for Interact-scale Systems[C]// USENIX Annual Technical Conference. 2010, 8: 9.

[11]Sigelman, Benjamin H., et al. Dapper, a Large-Scale Distributed Systems Tracing Infrastructure. Technical report, Google, 2010

查看原文

赞 2 收藏 2 评论 0

博云技术社区 发布了文章 · 2020-09-08

边缘计算,如何啃下集群管理这块硬骨头?

导读

边缘计算平台,旨在将边缘端靠近数据源的计算单元纳入到中心云,实现集中管理,将云服务部署其上,及时响应终端请求。

然而,成千上万的边缘节点散布于各地,例如银行网点、车载节点等,节点数量甚至可能是几万到十几万,这就会对节点的承载能力造成巨大冲击。Kubernetes 官方数据是可以支持纳管 5000 节点,如果想要纳管更多的边缘节点,该如何设计边缘计算平台架构呢?

本文针对以上问题,提供一些博云的解决思路。

多集群管理

多集群可以有效地扩展纳管节点的规模,而对 kubernetes 多集群的管理,各厂商的实现方式各有不同,不同的 API,不同的特性,因此市场上很难形成标准的解决方案。

现有的官方 kubernetes 多集群管理解决方案是 kubefed(Federation V2),即 kubernetes 联邦。Federation V1早在 kubernetes 1.6 版本就开始提供服务,但由于V1架构的限制,无法灵活支持更新的 k8s API 接口,加上其他很多问题影响集群管理的效率,因此 Federation V1 在 kubernetes 1.11 版本正式被弃用,现在提供服务的是 Federation V2。

由架构图实现可以看出,Federation V2 在 k8s 之上定义了一些资源,用 cluster configuration 记录集群的 endpoint,secret 等认证信息,type configuration 来定义需要用 Federation 托管的资源类型,提供了调度器来平衡各个集群的负载,以及多集群的 DNS 功能。

这种 controller 级别的集群管理,提供了丰富的集群间交互功能,更适用于异地多中心的集群灾备等场景。在边缘场景,一个边缘端可能就是一个小集群(存在多个计算单元可以组成集群),这样会使得集群数量不断增多,进而对 Federation 的执行效率、API 的响应时间都会有较为明显的影响。那么,该如何削弱集群数量的不确定性所带来的影响呢?

下面为大家展示,我们在 KubeEdge 架构下如何解决多节点的问题。

Cloudcore 横向扩展

KubeEdge 架构下的云边协同通信采用 websocket 方式,quic 作为备选。其中 websocket 性能最好,quic 在弱网络(频繁断开)情况下优势较大,通信的服务端都是由 cloudcore 来实现。

这里我们引入一个逻辑集群的概念,即每个 cloudcore 可以看做是一个集群,横向扩展多个 cloudcore 对接下层数量较大的边缘节点,向上只依托在一个 kubernetes 集群即可,架构如下所示:

这样设计有如下几点优势:

  • 解决单个 cloudcore 消息转发/接收等处理的性能瓶颈;
  • 应用/设备的发布请求在 api-server 会被 cloudcore 监听捕获到,转而由对应的 cloudcore 来处理请求到边端,这样缓解了 k8s 集群的压力;
  • 中心云只需要一套 k8s 集群,调用链简单清晰,易于管理。

测试实现

环境信息:

测试集群单 master 节点,管理一个 node1 工作节点,cloudcore 运行在 maser 节点上,并已接入 edge1 边缘节点。

现在测试 node1 上创建 cloudcore 服务,将新的边缘节点 edge2 接入,节点组图如下:

集群下已有 cloudcore 和 edgecore,node1 是 k8s 的 x86 普通节点,现在该节点上运行 cloudcore 提供服务。

  • 拷贝 cloudcore 二进制文件
  • 重新生成证书
  • 生成 cloudcore.yaml 配置文件
  • 拷贝 k8s 集群的 kubeconfig 并将路径配置到 cloudcore.yaml
  • 启动 cloudcore

edge2 是作为待接入集群的边缘节点,在该节点上运行 edgecore, server 指向 node1,启动服务。

可以看到 edge2 已经注册到 node1 上的 cloudcore 并同步节点信息到 k8s,测试发布服务到 edge1 上:

总结

本文通过讨论多集群的方式来扩展纳管边缘节点的规模,分析了以 kubefed 联邦进行多集群管理机制,对比不同场景下的特点,介绍了 KubeEdge 中利用横向扩展 cloudcore 的解决方案,并在测试环境部署实践。

在实际生产环境中,博云 BeyondEdge 边缘计算平台依托于博云 BeyondContainer 容器云平台,提供云上服务的编排、治理、DevOps 等云原生能力,利用 KubeEdge 将这些能力延伸到边缘节点,并将边缘设备抽象到云端 BeyondContainer容器云中,作为孪生设备资源,统一访问入口。

并且,运行在云端的边缘平台组件 cloudcore 作为应用服务部署在BeyondContainer容器云中,充分利用容器云的产品能力,将 cloudcore 以高可用方式部署在 kubernetes 中心云,通过 ingress 暴露服务接口提供给边缘节点的组件 edgecore 访问,可以根据边缘节点实际接入量动态扩展 cloudcore,作为逻辑上的集群扩展以提高中心云对边缘节点的承载能力。

查看原文

赞 0 收藏 0 评论 0

博云技术社区 发布了文章 · 2020-09-07

你问我答:容器平台改造后的安全是如何解决的?

BoCloud博云微信公众号【你问我答】小栏目,将收集和整理企业在IT建设所遇到的问题与难题,由博云产品与技术团队进行针对性回答,每周五通过【你问我答】栏目进行发布,希望能为企业IT建设提供思路与方法。无论您是哪个行业的IT建设者,如果您有在容器云平台建设、微服务架构转型、DevOps平台建设、多云管理平台建设等技术方面所遇到的问题,欢迎您直接评论留言提问。

以下是本周问题精选:

网友1:容器平台改造后的安全是如何解决的?

传统的单体应用的安全边界清晰,安装Agent就可以解决大量的监控木马入侵的问题,但是容器平台的共享内核特性、无状态特性,造成了安全便捷的不清晰,传统的安全产品因为网络的原因也无法对容器内的网络进行监控,所以改造后安全的问题怎么进行解决?是通过三方产品么?

博云产品团队:针对安全问题,可以参考商业化的容器云平台解决方案,提供多维度安全设计,保证系统数据安全、环境安全、网络安全、运行安全等全面的要求。在容器主机操作系统本身提供的安全措施(Linux 命名空间、安全增强型 Linux (SELinux)、Cgroups、功能和安全计算模式 (seccomp) 等)之外,商业化的容器云解决方案中,还可以在安全层面提供以下措施:

  1. 支持HTTPS安全协议访问、非root用户部署及管理、终端访问安全限制。
  2. 提供基于角色的访问权限控制功能,管理提取和推送特定的容器镜像的权限,保证租户隔离,资源隔离。
  3. 自动化安全测试功能整合到构建或 CI 流程,如应用安全扫描,保证镜像安全。
  4. 网络隔离:借助网络命名空间,各个容器集合都能获得自己所要绑定的 IP 和端口范围,因此能使节点上的容器集网络相互分隔开;利用路由器或防火墙的方法来控制出口流量的容器平台,以便利用 IP 白名单来进行控制(例如,控制数据库访问)。
  5. API 管理/端点安全和单点登录 (SSO)。

网友2:保险行业中上容器云项目的企业多吗?现在是什么形势?

博云产品团队:**未来保险要从主要依赖销售,转向依赖从头到尾的动态大数据风控。如今“互联网”思维+最新科技手段,已经深刻地影响、甚至是震动着每个行业,保险业自然也不例外。从管理模式、业务流程、经营模式、风控方式、到营销模式、产品开发、服务客户方式等各个方面,保险业正在被深刻影响着。而这些对保险公司来说都意味着内部的变革。

目前在国内外保险企业中,均启动了新一代信息系统建设计划。它旨在通过容器云、微服务、DevOps、应用大数据、物联网、人工智能等新技术,打造具有快速交付能力的、安全的、以客户为中心的、能满足现在及未来发展需要的“IT生产力”,从而使企业能快速、灵活应对业务发展的变化,并实现业务和服务创新。

针对此问,举例说说我的看法。众所周知,保险业务越来越多样化,尤其各种促销活动也越来越多,因此对于系统的快速扩展能力有很高的要求。保险行业里,运营活动促销、开门红促销等活动频繁发布,尤其是“秒杀”这一促销手段,这对保险公司来说,无疑是对其系统性能极限和灵活性的巨大挑战。如果系统按“秒杀”的峰值配置资源,那么平时资源利用率低,无疑是一种巨大的浪费。因此,就要求IT资源和服务可快速弹性扩展。

那么容器云平台的建设在未来保险行业的IT建设规划中必定是计划之一,目前国内保险行业在容器云的建设上还处于初级起步阶段,勇于尝试的企业还不多,大多处于调研、测试阶段,但随着未来1-3年业务的爆发增长以及应用服务的多元化,相信各大保险公司将在建设容器云PAAS平台上发力。

网友3:Docker的应用越来越多,与虚拟机的核心区别是什么?

博云产品团队:VMWare/OpenStack的虚拟化技术为我们打开了一扇新的大门,原来我们可以不用如此麻烦的管理物理机,采用虚拟化的技术,同时辅助各种工具,可以更好的实现对资源的管理,提高资源的利用率。当没有容器技术时,为了实现应用的快速发布和运维,会有两个问题:

1.应用以虚拟机镜像的方式发布:相比于容器镜像,因为要包含内核以及操作系统的文件,所以会大很多。另外镜像构建和编辑的过程不如容器镜像方便。

2.服务调度以虚拟机的粒度实现:由于虚拟机内的进程要多很多,一方面会造成资源浪费,另一方面,在评估资源占用率上,虚拟机也没有容器方式更加科学和准确。

如果没有虚拟化,容器编排系统Kubernetes直接接入物理机,如果说在私有云情况下还可以通过一系列物理机纳管工具实现灵活的资源分配与回收,那么在公有云场景下,厂商将自己的物理服务器都拿出来供用户自由申请分配,单是想想就能明白,对用户来说成本只会高不低,推广难度自然是很大。当然,为了特定的需求,公有云厂商为用户直接提供特定硬件的服务器,甚至是托管数据中心,是另外一种场景了。

总的来说,虚拟化技术使得数据中心内的管理对象从静态的物理机编程到动态的虚拟机,容器技术则是在虚拟化技术基础之上实现应用的打包构建、部署调度和运行,二者绝不是为了解决同一种问题搞出来两种方案,而是互为补充,二者结合起来才使得云计算IaaS/PaaS理念真正落地。

网友4:微服务和容器之间是什么关系?

博云产品团队:微服务是一种架构风格,是一种使用一套小服务来开发大型复杂软件应用的方式途径。

容器是一种运行时技术,允许许多应用以互相隔离的方式运行在虚拟机、物理机等之上。同时,分层的容器镜像技术、类似Kubernetes的容器编排技术等的出现,使得运维人员管理成百上千的应用实例变成了非常简单的一件事情。

所以可以看到,使用容器技术作为微服务架构的基础,是非常自然不过的选择。

查看原文

赞 0 收藏 0 评论 0

博云技术社区 发布了文章 · 2020-09-01

你问我答:现有的应用有必要做微服务改造吗?

BoCloud博云微信公众号【你问我答】小栏目,将收集和整理企业在IT建设所遇到的问题与难题,由博云产品与技术团队进行针对性回答,每周五通过【你问我答】栏目进行发布,希望能为企业IT建设提供思路与方法。无论您是哪个行业的IT建设者,如果您有在容器云平台建设、微服务架构转型、DevOps平台建设、多云管理平台建设等技术方面所遇到的问题,欢迎您直接评论留言提问。

以下是本周问题精选:

网友1:现有的应用不是微服架构,有必要做改造吗?

博云产品团队:其实使用微服务架构还是使用原本的单体架构,都取决于需求,那么问题就是我们目前是什么样的需求。需要微服务架构的,一般面临以下几个需求:

  1. 更新迭代太快,而部署麻烦,每次都要花费很长时间,经常影响业务。
  2. 公司的应用有几十个,重复的模块很多,也无法统一管理,未来还有扩展的需求。那就不如趁早转微服务架构,另外需要一套服务治理平台。
  3. 应用中某模块使用频繁,并发率很高,或有高峰期,经常需要资源的扩容缩容,单体应用做集群部署勉强能满足,但运维成本翻倍上升,且可用性下降。

    网友2:微服务和容器之间是什么关系?

博云产品团队:刚接触容器的人,可以将容器与虚拟机类比来看,那么微服务是部署在容器中,或虚拟机中,或物理服务器中,都是可以的。

但是容器有其独特的优势,快速启停,独立进程等,可以弥补很多的微服务运维上的缺点,所以两者可以说是黄金搭档。

但是两者本身没有依赖性,都是独立的东西,只是两者的理念结合,会更加完美。

网友3:微服务框架部署时的业务连续性如何考虑?

近年金融行业,尤其是银行业监管越来越严格,对业务连续性要求的更高,银行系统对于由传统架构迁移至微服务有较迫切的需求,目前在实际部署系统时,一般需要考虑系统的同城双活或同城、异地多活,以保障业务连续性。

那么在迁移至微服务架构的过程中,微服务架构上对于双活、多活的需求是如何考虑的?如何实现异常情况下快速无中断切换、不同中心间数据一致性等问题是否有解决建议?

博云产品团队:这个问题相对复杂一些,需要考虑IDC的建设方案,网络方案,数据存储方案等。这不仅仅是微服务能够解决的问题,微服务只能解决业务单元拆分开发的问题。

网友4:某些业务场景下会存在不太好熔断的情况,那这些场景是否有好方案可以实现熔断机制?

举例来说:保险客户下单,需要前端出单系统查询客户的一些指标信息,来作为计算保费进行报价的依据,这种类似场景是否有好的方案可以实现熔断机制?

博云产品团队:可以考虑直接在网络层实现,根据出现系统的返回结果做信息匹配,如果不满足要求,直接触发熔断操作,可以参考服务网格的实现方式。

查看原文

赞 1 收藏 1 评论 0

认证与成就

  • 获得 29 次点赞
  • 获得 1 枚徽章 获得 0 枚金徽章, 获得 0 枚银徽章, 获得 1 枚铜徽章

擅长技能
编辑

开源项目 & 著作
编辑

注册于 2018-05-23
个人主页被 1.5k 人浏览