本文整理自腾讯云容器产品,容器解决方案架构团队的陈浪交在 Techo 开发者大会云原生专题的分享内容——一个优秀的云原生架构需要注意哪些地方。本文将会给大家分享云原生架构的特点和以及实践过程中的一些注意事项。
从CNCF给出的云原生官方的定义可以看出,云原生架构其实是一种方法论,没有对开发语言、框架、中间件等做限制,它是一些先进的设计理念的融合,包括容器、微服务、尽量解耦合、敏捷、容灾、频繁迭代、自动化等。
云计算发展到今天已经比较成熟了,同时伴随着开源社区的发展,有个明显的趋势就是云服务商都在努力提供一个平台无关的服务,也就是云原生服务,强大如AWS也没办法阻挡,这个趋势的演变也值得探讨,由于时间有限,线下有机会可以交流下。由于云原生技术跟平台无关,使得用户可以从适配各个云服务商中解脱出来,从而更加聚焦在业务本身。方便让大家对云服务商的云原生平台有一个比较感性的认知,我们一起来看下云原生服务的层级架构。
最底层是云服务商的物理机、物理网络以及物理存储,之上是虚拟化服务、包括租户隔离的网络、计算资源以及分布式存储。到了这层,云服务商提供的产品虽然大同小异,但都还是平台相关的。
关键就是在上一层的PaaS服务层,由它来适配各个厂商的计算、网络、存储资源,然后对用户提供统一的访问接口,具体起来就是云服务提供商的Kubernetes服务在内部会去对接底层的存储、计算网络、再加上标准的mysql、redis等开源服务。这样用户对接的就是一个标准接口的PaaS平台,就为我们的业务从本地开发环境无缝迁移到公有云、甚至在云服务商之间迁移、混合云、跨云容灾等提供了技术前提。
结合以上介绍的背景以及云原生的定义,我们再总结下什么是云原生架构,一个平台无关的、自动化的、具备容灾能力的敏捷的分布式业务系统。
接下来介绍,在构建云原生服务时,有哪些注意事项以及一些个人的一点思考。
CNCF提供的云原生的定义对云原生做了经典概括,下述所讲内容也在它的定义范畴之内,包括为什么要做微服务拆分,为什么要容器化、如何做CICD、如何避免故障、以及故障发生时我们有哪些应对措施,最后一起交流下如何检验我们的系统是否符合云原生架构。
我们在讨论微服务时,其实讨论的是一个业务模块的微服务拆分是否彻底,这决定我们业务模块能否做到横向水平扩容、整体能否成为一个分布式系统。比如一个商城系统,库存服务逻辑变化了是否会影响到商品服务、订单服务,到双十一的时候,订单服务需要大幅扩容,我们能否只扩容一个服务、跟这个服务相关的数据库表而不影响其它服务。
因此,我们需要尽量减少服务之间的业务逻辑耦合、数据耦合,通过通信来进行数据共享,而不是通过共享数据来进行业务通信,使得我们在做必要的变更时,影响的范围能降低到最小。
容器是云原生架构的基础,这是容器的标准化属性来决定的,如果不使用容器,CICD、自动扩缩容就没办法做,我们不知道这些服务依赖什么配置、程序如何启动、如何停止,我们可以基于自身业务特性自己开发一套CICD系统、扩缩容系统,但是不是通用的,无法移植的。
有人说没有集装箱就没有全球化,这里的容器就是集装箱,大家想是不是这个道理。容器还有很多优点,首先可以降低成本,K8s知道如何调度把容器到合适的机器上,使得集群节点使用率均衡、并且提高节点的资源使用率,可运维性也上来了。