vlambda博客
学习文章列表

中小企业如何来思考Cloud native

随着虚拟化、云计算、微服务等各种技术的不断发展,人们从这些成熟的概念和技术身上看到了更多可能性和发展空间,Cloud-Native的提出无疑给我们建立一个更大的基础设施平台,除了统一计算、网络、存储等资源在多云之间切换更是带来了非常大的灵活性,大型公司和组织都早已在这上面投入了大量精力研究和尝试,比如2019年阿里宣称的双十一核心系统 100%上云,kubernetes+容器+service mesh 的大规模落地和实际业务考验,各大公司纷纷基于k8s来提升自身平台和技术,Cloud-Native的生态系统的发展足够强劲和开放,对于中小公司来说不存在壁垒和技术限制,这是大势所趋, 在打消疑虑看见趋势的情况下我们来看下Cloud-Native对于中小企业的意义,以及我们可以在那些方面思考做出改变?

我们主要谈以下几个问题:

  1. Cloud-Native的优势是什么?

  2. 中小企业为什么要思考和做出改变?

  3. 从哪些可行的方面去思考?


Cloud-Native的优势是什么


有效提高资源利用率,可以在同一个集群中部署多个服务来提高物理资源的利用率

提高系统的可用性和弹性,HA、容灾、水平扩展是其天生的能力,不需要为每一个服务做过多定制化的改动


在多云之间切换(无论是公有云、混合云还是私有云)提供了更大的灵活性,避免被云厂商绑定,甚至在需要的情况下你可以直接部署在自己基于Bear Metal的集群上


Cloud native 基础架构会大大的提高系统和服务的开发效率,开发只需要考虑达到cloud native的一些基本标准,你的服务自然就拥有了HA,容灾、水平扩展等能力


中小企业为什么要思考和做出改变


从开发效率上看,随着敏捷开发、Devops、SRE 等概念和技术的发展,我们发现理想情况下的工程师角色各负其职的情况应对现代技术行业的发展还是太过于理性了,团队的成员必须做到一精多通才能建立一个高效可靠的团队,Cloud native 可以在一定程度上为开发工程师提供一个基础平台的保障,避免开发工程师在底层基础平台上分散更多精力


从维护成本上来看,短期可能对于维护成本的投入可能会稍多,主要是公司内部的节奏、思维和技术的投入,一旦团队的姿势调整好整个团队的效率和应对需求的能力将会是一个大的提高,维护人员就会有一个明确统一的目标和平台,避免在各种底层环境下处理各种随时出现的零散的问题


从公司发展来看, Cloud native是行业发展的趋势,对于2C的企业自身的需求就会推动企业去在Cloud native上投入更多精力,对于2B的企业,B自身的发展将倒逼服务提供企业向Cloud native去发展,所以更早的考虑是有必要的,另外对于企业本身也是应对未来变化的更好投资

        

从哪些可行的方面去思考


下面我们将从切实可行的角度来分析下当前很多系统业务系统)架构可能调整的地方,当然这些调整并不意味着你必须将系统部署在Cloud native平台上,这里更多的是讨论以Cloud native的概念来把限制系统发展的一些可能存在的问题进行调整和消除,提高系统部署的灵活性和应对未来环境的能力


存储,这里我们不讨论具体的存储技术,我们先主要讨论我们的软件系统中如何去思考存储的使用和策略、数据的存储形式等,我们这里分为文件存储和数据库存储,这里面可能涉及的问题:

以文件形式存储(无论是本地文件还是网络存储)数据要充分的考虑好数据路径问题,尽量避免系统内部数据写到随意的路径下,这样给系统迁移和维护带来大量的复杂工作,也不利于维护和管理,我们应该为系统内部数据包括系统Log数据顶的存储做好规范化的路径指导,让系统的开发和维护人员遵行统一的规范的规范去处理和维护系统数据,对于数据库存储系统要充分的考虑数据库的部署和迁移的灵活性,以及HA能力,避免因为数据库能力限制自身业务系统的扩展


计算,随着技术和业务的发展,现在早已不是单机可以扛起一个系统的时候了,系统服务的水平扩展能力是中小企业当前系统面临的一个主要问题,这里面要考虑到主要问题是系统服务的合理划分和状态管理,这也是为什么最近几年为服务发展比较快的原因,这里主要先考虑好将有状态服务和无状态服务做好区分,无状态服务可以很好的适应水平扩展能力,对于有状态服务要支撑良好的水平扩展能力就要将状态的管理提升到系统统一的级别,避免本地状态的存储,这里解决办法有很多比如依赖统一的状态管理里服务(可以是数据库或服务注册中心)


网络,网络方面的限制相对较少,主要是避免单个服务和IP的绑定和服务端口映射的问题,避免在使用dns等技术的时候的缓存等问题


通信,这里涉及服务发现、服务之间通信、与服务能力外放等问题,服务发现的问题相对容易解决,很多成熟的分布式服务注册中心(ZookeeperEurekaConsul、etcd 等都可以作为服务注册中心解决方案)可以选择,对于服务之间的通信,同样我们有很多开源的成熟的技术可以选择比如,比如ZeroC的ICE,Facebook 开源的Thrift、和现在被大部分开源系统使用给gRPC都支持多语言的开发,并对于集成服务注册中心相对简单和灵活,那么中小企业可能做的就是选择一个合适自己的RPC技术,并确定是否需要监控rpc的性能


对于中小企业来说可能马上把系统调整到Cloud native的规范下不太现实,但是应该尽早的考虑和消除当前系统架构和部署可能存在的一些限制问题,这些问题的消除将有助于系统的维护和管理,提高团队的开发效率,做到本地部署的情况下也尽力那个考虑Cloud native的概念,这样系统在未来应对系统部署环境的时候会非常容易调整,尽量满足在裸机和各种云环境下部署的一致性,来应对未来的挑战