云原生架构漫谈

技术的本质

解决重复或者需要人工干预的问题。
比如spring解决了重复创建对象、人工编码管理对象、人工实现依赖等问题;
maven解决了项目手工构建、工程间依赖问题;
docker解决了环境无法方便的转移等问题;

技术的痛点

代码运行最终依赖cpu、内存、硬盘等物理资源,而单机的物理资源增长受到限制,况且物理资源最终是要花真金白银购买的,做技术时就免不了考虑是升级一台机器和购买多台机器哪种方式性价比高。
经过不断的实践,我们得出了结论,项目要做成一定的规模,最终的思路还是变成分布式的,也就是走购买机器的方式。
规模化之后负载均衡,高可用,事务也是亟需解决的问题。


我们在做技术架构,最终目标是要充分地利用这些物理资源去实现我们的显示需求

比如mysql,如果数据存储在机械硬盘上,读写非常的慢,这是受到磁盘机械臂寻址定位的“龟速”制约,而电路高低电平驱动显然会比这种方式要高效得多,但当前用ssd成本又高了很多,所以我们会使用缓存中间件去帮我们做一层过滤,如果缓存有数据就不必再去读库。如果有一天ssd成本降低得比机械还要低会发生什么事呢?也许我们就不必再用缓存了,编码也会简单很多,我们要做的只是给mysql加机器就行了。

项目的运行又受到为什么限制呢?

项目部署到物理机器上,如果内存溢出可能会导致宕机或者项目停止,这是无法忍受的,所以物理资源都要预留一部分出来,这也是一种资源的浪费。另外,物理机器的采购、审批也要一定的时间,这也会制约需求的快速迭代。

如果部署多两台,三台,甚至上万台,如果是人工配置的方式,那得几百号人,而且协作也是个问题;我们自然会想到用脚本去做,运维可以缩减到十人以内。

运维是怎么做的呢?发现请求量上来,可能就去申请机器,然后手工配置,这个过程重复而且需要人工去做,可能涉及到财务审批,效率十分低下,就跟机械硬盘跟ssd做对比一样。

我们可以得出一个结论,凡是需要人工干涉的在规模化之后都会遇到瓶颈,都需要一种新的技术解决,而引入新的技术后仍然可以套用此结论。

云原生架构的诞生

代码运行在物理资源上,而物理资源无法自动地去伸缩去适应代码的硬件需要。

假如平台没人访问,我们希望它的费用消耗为;
如果代码访问的人周期性的或多或少,我们希望消耗的物理资源也跟着这个规律走,付的钱也是忽高忽低,这样性价比才最高,不是吗?

因此物理资源要做到动态伸缩,自动管理,需要容器编排这种能力;
每种业务消耗的物理资源特点不同,业务发展路径也不同,迭代速度也不同,因此我们需要微服务的能力,这样就能多业务线并行开发了;
项目开发完之后,测试、构建、发版到各个服务器、运行、通知等步骤都是重复的,我们用DevOps来解决,这样运维的工作就不至于那么简单重复;
有了以上三种能力之后,我们就能更专注地开发具体业务,也就有了持续交付的能力;
——这就是云原生架构
img
2.jpg

参考

云原生架构的十二要素

12-Factors经常被直译为12要素,也被称为12原则,12原则由公有云PaaS的先驱Heroku于2012年提出(https://12factor.net/) ,目的是告诉开发者如何利用云平台提供的便利来开发更具可靠性和扩展性、更加易于维护的云原生应用。具体如下:
img
– 基准代码
– 显式声明依赖关系
– 在环境中存储配置
– 把后端服务当作附加资源
– 严格分离构建、发布和运行
– 无状态进程
– 通过端口绑定提供服务
– 通过进程模型进行扩展
– 快速启动和优雅终止
– 开发环境与线上环境等价
– 日志作为事件流
– 管理进程

另外还有补充的三点:
– API声明管理
– 认证和授权
– 监控与告警

1. 容器化封装

最近几年Docker容器化技术很火,经常在各种场合能够听到关于Docker的分享。Docker让开发工程师可以将他们的应用和依赖封装到一个可移植的容器中。Docker背后的想法是创建软件程序可移植的轻量容器,让其可以在任何安装了Docker的机器上运行,而不用关心底层操作系统。

Docker可以解决虚拟机能够解决的问题,同时也能够解决虚拟机由于资源要求过高而无法解决的问题。其优势包括:

  • 隔离应用依赖
  • 创建应用镜像并进行复制
  • 创建容易分发的即启即用的应用
  • 允许实例简单、快速地扩展
  • 测试应用并随后销毁它们

自动化运维工具可以降低环境搭建的复杂度,但仍然不能从根本上解决环境的问题。在看似稳定而成熟的场景下,使用Docker的好处越来越多。

2. 服务编排

笔者看到Jimmy Song对云原生架构中运用服务编排的总结是:

Kubernetes——让容器应用进入大规模工业生产。

这个总结确实很贴切。编排调度的开源组件还有:Kubernetes、Mesos和Docker Swarm。

Kubernetes是目前世界上关注度最高的开源项目,它是一个出色的容器编排系统。Kubernetes出身于互联网行业的巨头Google公司,它借鉴了由上百位工程师花费十多年时间打造Borg系统的理念,通过极其简易的安装,以及灵活的网络层对接方式,提供一站式的服务。
Mesos则更善于构建一个可靠的平台,用以运行多任务关键工作负载,包括Docker容器、遗留应用程序(例如Java)和分布式数据服务(例如Spark、Kafka、Cassandra、Elastic)。Mesos采用两级调度的架构,开发人员可以很方便的结合公司业务场景自定制MesosFramework。

他们为云原生应用提供的强有力的编排和调度能力,它们是云平台上的分布式操作系统。在单机上运行容器,无法发挥它的最大效能,只有形成集群,才能最大程度发挥容器的良好隔离、资源分配与编排管理的优势,而对于容器的编排管理,Swarm、Mesos和Kubernetes的大战已经基本宣告结束,Kubernetes成为了无可争议的赢家。

3. 微服务架构

传统的Web开发方式,一般被称为单体架构(Monolithic)所有的功能打包在一个WAR包里,基本没有外部依赖(除了容器),部署在一个JEE容器(Tomcat,JBoss,WebLogic)里,包含了DO/DAO,Service,UI等所有逻辑。其架构如下图所示。

3.jpg

传统的单体架构

单体架构进行演化升级之后,过渡到SOA架构,即面向服务架构。近几年微服务架构(Micro-Service Archeticture)是最流行的架构风格,旨在通过将功能模块分解到各个独立的子系统中以实现解耦,它并没有一成不变的规定,而是需要根据业务来做设计。微服务架构是对SOA的传承,是SOA的具体实践方法。微服务架构中,每个微服务模块只是对简单、独立、明确的任务进行处理,通过REST API返回处理结果给外部。在微服务推广实践角度来看,微服务将整个系统进行拆分,拆分成更小的粒度,保持这些服务独立运行,应用容器化技术将微服务独立运行在容器中。过去设计架构时,是在内存中以参数或对象的方式实现粒度细化。微服务使用各个子服务控制模块的思想代替总线。不同的业务要求,服务控制模块至少包含服务的发布、注册、路由、代理功能。

容器化的出现,一定程度上带动了微服务架构。架构演化从单体式应用到分布式,再从分布式架构到云原生架构,微服务在其中有着不可或缺的角色。微服务带给我们很多开发和部署上的灵活性和技术多样性,但是也增加了服务调用的开销、分布式系事务、调试与服务治理方面的难题。

4.png

Spring Cloud整体架构图

从上图Spring Cloud组件的架构可以看出在微服务架构中所必须的组件,包括:服务发现与注册、熔断机制、路由、全局锁、中心配置管理、控制总线、决策竞选、分布式会话和集群状态管理等基础组件。

5.png

Spring Cloud VS Kubernetes

Spring Cloud和Kubernetes有很大的不同,Spring Cloud和Kubernetes处理了不同范围的微服务架构技术点,而且是用了不同的方法。Spring Cloud方法是试图解决在JVM中的微服务架构要点,而Kubernetes方法是试图让问题消失,为开发者在平台层解决。Spring Cloud在JVM中非常强大,Kubernetes管理那些JVM很强大。看起来各取所长,充分利用这两者的优势是自然而然的趋势了。

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注