当红架构Cloud_Native_怎么搭建才能成为上云助攻手?

一、什么是Cloud Native?

说到Cloud Native,国内大多数都翻译成云原生,就是让云成为成功的基石,而不是障碍。陈谔对于为什么要实现云原生应用深有体会,网易从2012年开始实施云化的战略,当第一版云计算平台建好的时候,开始引导公司的项目逐渐向云迁移。这个过程中就遇到了一个问题:用上云之后,并没有变得效率奇高,甚至有些项目的效率反而有所下降,大家都有很多抱怨。

从那时陈谔就有一个想法,云计算怎样才能成为公司和开发团队成功的基石,而不是用上云之后给你制造麻烦。他认为要做到这一点首先要理解云的优势,规避云的弱点;另一方面要充分利用云的各层能力,帮助你去成功。所以云原生就是采用适合云端的软件架构和研发模式去做这个事情。

二、如何实践云原生?

关于如何实践云原生,陈谔为大家分享了一些建议。假设大家不是类似BAT这样规模的公司,或者有非常强大的IT团队,在选择技术路线时,陈谔建议大家使用公有云,为什么呢?

1、使用公有云

 弹性

首先,使用公有云起步的成本非常低,不需要你去租机房、买物理机,每个月几百块钱就可以起步了。如果你成功了,在爆发性增长时,公有云也有足够大的资源弹性帮助你从一台Scale到几百台,而不需要临时去买服务器。

 网络质量

另一方面,由于公有云的规模化效应,网络质量是自建不可比拟的:

  • 有些公有云出入口的带宽很大,甚至有些互联网大厂的公有云平台,用的基础设施跟公司整体业务是一体的;
  • 带宽大的另一个好处是可以抵御DDoS和CC攻击;
  • 其次,公有云有更强的排障能力。国内的国情,网络故障是非常难以排查的,需要有专门的IT团队才能做好。

 Managed Cloud Service

云计算有数据库、中间件这些服务,并且不需要你去关注高可用部署、故障恢复、扩缩容等系统层面的运维,操作系统内核级掌控、中间件源码级维护也均由云提供商负责,并且有明确的SLA保障。

 高可用保障

此外,云计算可以帮你做高级别的高可用保障。日常的高可用保障,比如双机热备也好,冷备也好,都比不过公有云提供的多可用区的保障。云的多可用区至少是IDC级别的,在一个可用区内就像一张大网一样,至少保证三层的连接,保证你的业务都是互通的,整体架构不用考虑跨机房的问题。

云还有多Region的保障,有一些公司会做异地多活的架构,当然这对业务的侵入性是很大的,但至少可以用多Region的设施,来做数据的灾备。

另外,云的进化速度很快,会持续地更新,现在大多数都是基于Linux的技术栈,可能会不时地出现bug或安全漏洞,如果自己去跟进是非常困难的,公有云一般都会有专业的团队,及时跟进和修复这些安全问题,又省下了用户一笔人员开销。

 公有云的取舍

当然,公有云要支持这么大规模的用户,本身有一定的取舍。

1)Design For Failure:公有云倾向于更快失败(影响范围受控)、更快恢复。如果你用的是物理机,出现问题时你会关注这个物理机是不是还“活着”。而公有云如果发现一台机器挂了,会直接进行服务迁移和重启,因为公有云本身有SLA的承诺,为了保证系统的鲁棒性,会更快地把这些疑似故障的节点排除掉。

2)由于公有云这样的特性,日常业务必须结合公有云能力实施高可用架构:

  • 一方面以可用域为基础,实现高可用;
  • 另一方面,将数据状态和业务逻辑分离,如果业务被迁移走了,只要挂上原来的盘就可以恢复了;
  • 节点可重启或重建。

3)Design For Scale:虚拟化性能稍弱于物理机,公有云更追求交付的性能指标的稳定,避免租户业务间的影响,支持业务做Scale。对于开发者来说:

  • 一方面,要知道你采购的磁盘、网络能够提供的性能是什么,根据这些QoS指标去做容量的规划;
  • 另一方面要基于负载均衡、集群管理等能力去做Scale Out,而不是让机器规格越变越大。

2、项目工程化

除了上面提到的基础设施,在项目的工程化方面,陈谔也为大家带来了一些启示。他认为项目工程化是研发协作与云端运维的基础,也是很多团队在起步时可能会忽视的事情。项目的整个流程中,开发、测试、发布的每一步都涉及到公司内角色之间的协作,如果这些步骤做得不流畅,每一个环节的衔接非常困难,效率就会变的非常低,所以项目工程化是对高效构建、发布、运行流程的支持。

 合理的版本控制工具

那么,如何做到项目的工程化呢?首先要选择合理的版本控制工具与策略:

  • Git是社区和业界公认的一个比较好的工具;
  • 建议每个应用采用单一的Codebase(12Factors-1: Codebase),把整个开发,构建,发布的流程串联起来,不至于拉下一个base还要决定这里面的代码哪一部分要拿去构建。

常见的版本控制策略包括:

  • 基于Merge的多分支策略,这种模式和多人协作的方式是匹配的,可以看到大家协作产生的代码从分支到合并的过程,但是分支很多也造成了管理的复杂度很高;
  • 如果团队能切割得比较小,功能比较集中的话,可以采用基于Rebase的单Master分支策略,它没有Merge信息,管理起来比较简单。

 基于配置的依赖管理

然后可以去做基于配置的依赖管理:

  • 声明依赖(Maven等),而不是把你的软件包全拷贝在代码库下面,实现自动构建
  • 建议声明所有的依赖,包括运行环境的初始化,不隐式依赖系统库(12Factors-2: Dependencies)

接下来要合理拆分模块,可以按业务拆分模块,同时实现公共代码的模块化。

 使用Docker实现环境一致性

之前在网易,对稳定性要求很高的产品,其发布流程通常都很曲折,主要原因在于环境的不一致。陈谔的建议是使用Docker实现环境的一致性,Docker容器完整虚拟化了Linux操作系统,将业务代码与运行环境装箱为Docker容器发布到生产环境,差异仅仅为外部注入的配置(如数据库地址等),容器内部文件在开发环境一旦发布则不再变化,从而保证开发环境与生产环境一致。

3、服务化的思维

工程化是做业务架构,建立一个高效团队的基础,接下来要考虑的就是服务化的思维。微服务是当下很流行的概念,采用微服务确实能为应用的迭代和架构带来很多好处。但服务化的架构会带来额外的负担,如果一个项目还处在初期阶段,我们的建议则是服务化思维先于服务化架构。

  • 运维成本:一旦服务多了,环境搭建、故障诊断、运维的工作量都会成倍增加;
  • 服务拆分之后,各个服务间的生命周期是不一致的,要做生命周期的分离,就需要处理更多的异常。服务间存在更多的约束,还是异步的,如依赖关系、版本,要保证消息能够可靠地到达那里;
  • 另一方面,还会有分布式事务的问题,虽然解决起来不难,但是会侵入你的业务。

虽然业务初期,不适合服务化,但应该为后续的服务化做一些准备,否则后面想拆分的时候会变得非常困难:

  • 提取Service API,理解业务中的服务抽象;
  • 数据库设计的时候就考虑服务的划分;
  • 避免跨服务事务,对跨服务事务进行标记;
  • 如果项目发展起来,遇到的第一个问题通常是数据库会挂掉,所以在业务初期就做分库分表是很有必要的;
  • 选择事务支持更好的数据库,如果你用缺乏事务支持的数据库做业务的后端,当你要做服务化拆分或分布式事务的时候,可能会比用MySQL的痛苦很多。

4、实施微服务

随着业务的壮大,是否要采用微服务,就要去衡量微服务带来的收益是否大于成本?

 收益

  • 控制迭代更新的影响域,而单体架构很难评估patch的影响范围;
  • 加速迭代,提交代码心里负担小,迭代也能加快;
  • 隔离局部故障;
  • 防止代码架构层面的腐化,比如开发过程中为了赶进度,可能会把原有的架构推倒重来。如果用微服务架构,最多只需要将自己负责的那个模块重新设计。

 成本

  • 更多的依赖(eg: ZooKeeper,MQ),要做一个注册中心;
  • 运维复杂度,几十个服务发布更新,运维的复杂度必然会上升;
  • 技术实现的侵入性,在这个过程中难免要用到一些微服务化的框架,虽然对代码的侵入性不大,但对架构的侵入性还是不可避免的。

 降低实施成本

  • 良好的工程化,不要给运维的工作带来很多困难;
  • 使用基于云端托管的PaaS服务;
  • 使用基于云端托管的编排服务,帮你去做集群化的运维和管理的工作。

 基于Kubernetes简化微服务实施

利用基于Kubernetes的基础设施可以简化微服务,一方面Kubernetes提供了基于域名的服务发现:

  • 使用VIP+域名暴露服务:对比“注册中心”,采用域名服务具有更小的侵入性,更少的依赖
  • 支持名称空间隔离,简化测试环境部署

Kubernetes还可以做基于iptables的透明RPC分发:

  • 无需在程序中访问注册中心获取成员列表进行软负载均衡;
  • 无需内网负载均衡层次增加网络开销。

比如,服务A访问服务B的虚拟IP VIP,利用iptables做DNAT,转成B中的所有成员,服务A可以直接,并利用probability特性按权重分发请求,比域名做轮转的负载均衡效果要好,因为iptables可控,域名不可控。

用Kubernetes还可以让你获得自动化运维能力:

  • 自动扩缩容
  • 自动故障处理(重试、迁移)
  • 自动化滚动更新,通过健康检查与滚动的配合实现无缝更新
  • 还可以基于Service 抽象实现蓝绿发布

Kubernetes以解耦的基础服务层的方式提供了对服务化的支持,避免了代码实现层面的耦合,通过云端托管Kubernetes服务能够将实现服务化的成本大幅降低。而且Kubernetes对业务没有侵入性,实现服务化的代价相对会比较小,后面业务变得非常重,需要细粒度控制时,再用到其它框架也没有什么影响。

我们深度整合了Docker技术和Kubernetes集群编排技术,所以网易云中会有一个Kubernetes Master,所有租户的业务都可以使用这个Master,不用用户自己维护。

5、DevOps

前面讲到的都是云原生相关的技术,实际上实现云原生还需要一些研发、运维和组织架构上的方式调整,比如DevOps。DevOps的出现是为了解决运维角色与开发角色的矛盾,运维追求的是可用率优先,而开发希望应用能快速更新迭代。

 DevOps 与微服务

微服务架构能够支持更高频的迭代,降低更新迭代的风险,这与DevOps的目标是一致;但是微服务架构也会给运维带来成倍的工作量,可基于DevOps分散运维操作,而不是集中依赖少量运维角色。

 实施DevOps

实施DevOps需要CI/CD、编排、故障诊断等工具链的支持,同时需要运维实现从操作到审计的职能转换,运维工作前置,在前期和开发团队合作。很多运维还需要开发工具,提高运转效率。

 基于DevOps工具链支持微服务架构

1)Jenkins-容器-镜像仓库-服务编排

Pipeline as Code:实施服务化后持续集成的复杂度成倍增加,需要定义大量的流程,包含大量Jobs,以代码的方式管理Pipeline能够支持审计,有效管理复杂性并降低维护成本。

2)日志服务-分布式跟踪系统-性能管理服务

日志服务:Kafka+ELK套件,以网易云为例自动完成容器日志收集,并提供订阅接口可对接ELK。

分布式跟踪系统:在微服务架构下必须要做到与单体架构同样的服务请求的调用路径跟踪能力,才能够有效定位故障。可参考的框架有Zipkin,需要对RPC框架等做instrumentation,在调用过程中携带额外的头信息。

性能管理服务:微服务架构下依赖关系复杂,发生性能问题时难以定位源头及影响范围,性能管理服务可提供调用关系拓扑,及时统计慢响应及错误响应,有利于发现性能问题与定位故障。以网易云为例,利用Kubernetes提供元信息,利用AOP对常用库做instrumentation,可在无须配置及侵入代码的情况下,自动绘制拓扑,分析性能。

下图是我们内部性能管理的拓扑截图:

三、总结

最后,陈谔将云原生架构实现的要点总结如下,希望能给云计算的用户带来有价值的参考:

  1. 使用公有云;
  2. 重视项目工程化;
  3. 项目起步时建立服务化思维,而不要急于采用服务化架构带来不必要的负担;
  4. 实施微服务需权衡收益与成本,基于Kubernetes可简化微服务实施;
  5. DevOps能与微服务架构良好匹配,但实施DevOps需要完善的工具链支持。

原文地址:http://click.aliyun.com/m/21199/

时间: 2024-11-07 15:26:00

当红架构Cloud_Native_怎么搭建才能成为上云助攻手?的相关文章

三层架构初识和搭建

一.是什么? 1.表现层(UI):展现给用户的界面,用户在使用一个系统的时候他的所见所得.主要表示Web或WinForm方式,对用户的请求接受,以及数据的返回,为客户端提供应用程序的访问.如果逻辑层相当强大和完善,无论表现层如何定义和更改,逻辑层都能完善地提供服务. 2.业务逻辑层(BLL):针对具体问题的操作,主要负责对数据层的操作,对数据业务逻辑处理. 3.数据访问层(DAL):该层所做事务直接操作数据库,针对数据的增添.删除.修改.查找等具体为业务逻辑层或表示层提供数据服务. 二.为什么?

架构师初码邀你—浅聊上云思路

架构师初码邀你-浅聊上云思路 话题发布专家:初码--资深程序员,初级架构师,知名博主 在实践中,无论是个人站长还是中小企业,选择云服务,都会遇到如何上云的问题,这个问题的详细描述就是,应该选择怎样一种迁移和部署到云服务上的方式并且应该使用哪些云服务?今天我们抛开具体的技术和语言不谈,就可能出现的架构方式简单的聊一聊,以我个人的经验来看,有较多的遇到过如下3种上云场景 一.傻瓜型: 在云服务时代前,但凡提到建站,多数所指即使用虚拟主机搭建一个内容管理网站或者论坛社区网站,操作者只需要知晓简单的虚拟

如何自学Struts2之Struts2架构和环境搭建[视频]

如何自学Struts2之Struts2架构和环境搭建[视频] 之前写了一篇"打算做一个视频教程探讨如何自学计算机相关的技术",昨天晚上刚好有点时间,先做两个视频: http://v.youku.com/v_show/id_XODkyMTczMzMy.html 明天就回家过年了,家里没网络,等回来上海再继续弄吧,先给大家拜个早年,祝新春快乐,阖家幸福,事事如意!

如何快速构建中小企业应用上云架构的应对思路

好久没来了,这段沉浸的时间都在专注学习云计算相关的解决方案和进行实战,这一次更新那当然是有项目在个人的努力下,落地了!!!! 所以过来更新下,我在项目中的各个状态.当然仍然是用第一视角的去解读,这也是一次汇总和回顾,有很多主管的想法在里面,不喜勿喷. 先在"上菜"前,开放的聊聊我个人理解中的云计算是什么样子的?到底什么样的业务部署形式才属于真正的云计算部署?到底我们在云计算这样的趋势下如何合理运用好云计算的特点去提交合适的技术解决方案? 首先,我个人的总结了几点: 1. 改变了传统IT

鸟哥的 Linux 私房菜(服务器) 第三章 局域网络架构简介 第四章 连上 Internet

鸟哥的 Linux 私房菜(服务器) 第三章 局域网络架构简介 第四章 连上 Internet [TOC] 3.1 局域网络的联机 3.1.1 局域网络的布线规划 3.1.1-1 Linux 直接联网-与 PC 同地位 3.1.1-2 Linux 直接联网-与一般 PC 分开网域 3.1.1-3 Linux 直接联网-让 Linux 直接管理 LAN 3.1.1-4 Linux 放在防火墙后-让 Linux 使用 Private IP 3.2 本书使用的内部联机网络参数与通讯协议 3.2.1 联

数字化重构2.0,企业如何搭建AI与混合云架构?

IBM Think大会向来被誉为全球科技界的风向标. 在Think 2019上,IBM提出了数字化重构2.0的观点,企业80%的关键应用将在这一阶段通过转型完成上云,而这一阶段的商业数字平台需要衔接从改变客户体验向内推的和从改造核心应用向外推的数字化转型,人工智能将嵌入到这样的数字平台进而扩散到企业的方方面面,而这就需要Purpose-built计算架构,于2018年两次夺得了全球超算冠军的SUMMIT超级计算机就是典型代表. 今天,企业则面临着10~20种公有云以及公有云与私有云对接的混合云资

如何开始上云迁移

在企业里,许多上云迁移成功的案例,都是先从一些较为简单的应用开始迁移,然后再一步步把更多的应用和数据迁移到云,不可能同时把所有的应用都一下迁移过去. 对于要迁移上云的应用和数据,制定一份详细的计划与时间表是必要的,迁移是一个很复杂的过程,可以先从最简单的应用开始,然后再考虑复杂的.关联度比较高的业务,一些个性化的企业应用等. 如上图(图片来自网络)所示,描述了企业稳步进行云迁移的一般步骤,迁移是一个系统工程,迁移过快往往将导致成本的急剧上升.工期延期甚至失败. 上云迁移的过程,我们可以将其细化分

车联网上云最佳实践(一)

摘要: 最近两年车联网发展受到政府部门.科研院以及各大互联网巨头的广泛关注和积极推动.从应用来看,主要包括两种模式:一是前装模式(即车辆出厂前安装),是乘用车厂主导或者与有相关能力的公司合作,例如上汽和阿里巴巴的合作. 一.车联网行业特性讲解最近两年车联网发展受到政府部门.科研院以及各大互联网巨头的广泛关注和积极推动.从应用来看,主要包括两种模式:一是前装模式(即车辆出厂前安装),是乘用车厂主导或者与有相关能力的公司合作,例如上汽和阿里巴巴的合作.另一种就是后装模式(通常是将车机设备安装在汽车的

上云十年:阿里云的奇幻漂流

现代人的生活是不缺乏刺激的.我们总能在电影院或化身“沙发土豆”,作为旁观者,与凤凰社.夜魔侠.蜘蛛侠等诸多主角们经历了一场场“安全的冒险”,体会他们挣脱束缚的破釜沉舟,欣赏他们踏上未知冒险的勇气. 回到真实的商业故事中,很少有人会将阿里与“困境”这样的字眼联系在一起,尤其是在花团锦簇.全民狂欢的双十一之后. 但少有人知道,这场剁手党的“春晚”,却是技术人眼中冰峰林立.人迹罕至的“珠穆朗玛峰”.而阿里云的工程师们,刚刚经历过一场大汗淋漓的搏斗. 极致双 11:阿里云的技术攀爬 11 月 11 日