资讯中心
关于我们
欢迎光临格子云商城!
GE ZI CLOUD
数字化应用聚合平台
格子云
按钮文本
热门搜索:惠普  复印纸  中性笔
全部商品分类
技术社区

以业务为核心的云原生体系建设

来源: | 作者:创业观察 | 发布时间: 2021-02-04 | 6709 次浏览 | 分享到:
要做好整个企业的云原生体系建设,需要有个总体的视角,不谋全局者,不足以谋一域。我们将企业的架构进行全方面的梳理,并给出云原生体系建设总图,这个图当然不是一蹴而就就能建设完毕的,而是根据业务需求不断迭代演进出来的,但是我们要知道目标在哪里。1、企业架构的五个方面企业架构不仅仅是技术问题,还有流程问题和组织问题,总得来说分为五个方面,业务架构、技术架构、数据架构、研发流程和组织架构。 ...

基于OpenStack云平台,可以实现基于虚拟机镜像的运行环境,容器有镜像,虚拟机也有,在有容器之前,我们就可以对接持续集成平台,基于虚拟机的镜像实现应用的编排,将主流的运行环境全部打成镜像,并可以基于虚拟机镜像实现弹性伸缩。

基于OpenStack云平台以及虚拟机镜像,可以构建基于虚拟机的PaaS平台,也即数据库,消息队列,缓存等,都可以变成托管服务,让业务方点即可得,不用自己搭建,也不用考虑高可用如何配置,主备如何切换,PaaS如何扩容等等,这些全部由虚拟机镜像中的脚本自动化搞定。

在此之上是Kubernetes容器平台,他作为统一的编排层,可以将Vmware创建出来的虚拟机,KVM创建出来的虚拟机,以及物理机统一的纳管进来,还可以通过多Kubernetes管理,纳管公有云上的资源。Kubernetes里面的概念更贴近应用层,所以可以看成从资源层到应用层过渡的桥梁,将底层不同的资源全部屏蔽起来,对上提供统一的应用编排。Kubernetes的编排能力比OpenStack强很多,对概念的抽象也更加对应用友好,因而持续集成平台可以从对接OpenStack,慢慢切换称为对接Kubernetes,可以实现跨云编排,迁移,与弹性伸缩。

有了Kubernetes,就不用使用虚拟机镜像做应用运行环境了,Docker镜像就是天然的运行环境,而且更加的标准化,可以跨云迁移。另外有了Kubernetes Operator,可以基于容器实现PaaS平台,也即数据库,缓存,消息队列的编排。

在网上就是应用层了,这里以电商业务为例子,业务层已经实现了微服务化,封为两层,下层为中台层,也即可复用的能力,强调资源整合和能力沉淀,包括第三方商家,供应链,决策,用户,商品,社交,交易等基础服务。上层为业务应用,强调贴近用户,快速应对市场变化,包含的系统非常多。当然不是任何一个业务都是要一下子拆这么细的,而是逐渐拆分的,如何逐步拆分成这样,也是本课程的重点。

为了支撑如此复杂的微服务架构,需要配备相应的工具链,例如API网关,微服务管理与治理平台,APM性能管理平台,日志中心,配置中心,分布式事务等。当然这些工具链也不是一下子都用起来,也是随着微服务的不断拆分,逐渐的使用。

这些工具的采用都多少对于应用有侵入性,如果想让微服务的治理能力下层到基础设施层,Service Mesh是一个好的选择。

另外还要有端到端统一的监控中心,要下能够监控基础设施,上能够监控应用的运行,这样在定位问题的时候,才能够互相印证。

我们再来看左面的组织架构。

为了讲右面的技术架构运行起来,要改变原来CIO下面一个技术总监,一个运维总监的情况。由于整个技术体系比较复杂,需要整个团队基于统一的流程和规范,才能方便管理,而如何保证整个系统的运行符合这个流程和规范,仅仅CIO一个人的精力不够,需要有一个架构委员会,这里面有专职的架构师,包括云的,运维的,微服务的,QA的,项目管理的,另外架构委员会里面还应该有各个组架构师代表。架构委员会对于整个架构的运行,流程和规范的落地负责,并像CIO汇报。而且架构委员会会融合各个角色,不会出现开发和运维隔离的情况。架构委员会制定流程和规范,并要求各个开发和运维组执行。

开发组分成业务开发和中台开发组,业务开发组用于快速响应客户的需求,中台开发组不直接面向客户,每天想的事情就是能力如何复用,如何锻炼腰部力量,只有有一拨人专门考虑这个问题,才有可能积累称为中台。

业务开发和中台开发到底是否执行架构委员会制定的流程和规范,需要有一定的工具链的配合,因而就需要技术底座组,包括云,大数据,容器,微服务,已经相应的流程管理,规范管理,绩效看板等,可以让架构委员会通过工具链,实时审核架构当前的运行情况,并对不符合流程和规范的接口,测试,文档等及时纠正,并计入绩效看板。

看完了这些,你可能觉得,哇,云原生如此的复杂,直接放弃吧。

其实不是的,从来没有一种说法是一下子就达到这个状态,而且也不可能通过采购一个大平台,公司一下子就形成了云原生架构,这都需要迭代的进行,这正是要解决的问题。

接下来,我会逐层剖丝剥茧的解析这个迭代过程,主要的思路为:

  • 遇到什么样的问题?

  • 应该采取什么样的技术解决这个问题?如何解决这个问题的?

  • 这个技术的实现有很多种,应该如何选型?

  • 使用这个技术有没有最佳实践,能不能形成企业的相关规范?

三、云原生体系演进阶段一:拉通信息系统,重塑组织协同

我们来看第一个阶段,拉通信息系统,重塑组织协同。

我们分别从企业架构的五个方面依次阐述。

1、阶段一的现状

1.1、业务架构:单体应用,企业消息总线集成

我们还是从业务架构入手分析,大部分企业的信息系统并没有做到这一点——拉通信息系统,重塑组织协同,因为大部分系统都是外部采购,或者外包公司开发,由不同的团队进行维护,这些都是烟囱系统,信息零散,格式不一致,无法拉通,无法协同。