前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >云原生架构演进与企业上云

云原生架构演进与企业上云

作者头像
春哥大魔王
发布2020-02-19 10:56:44
1.6K0
发布2020-02-19 10:56:44
举报
文章被收录于专栏:服务端技术杂谈

过去的一段时间和一些架构师 / 技术负责人聊天,云原生和企业上云是最近一段架构演进的一个常见话题,那么小公司到大型公司在上云和云原生上有什么价值和收益呢。

云原生技术的里程碑

云原生的定义

  • 云计算的本质:按需分配资源和弹性计算
  • 互联网业务特点:快速迭代,逻辑复杂,海量用户,流量突增,7*24小时高可用

上云的价值

  • 业务上,研发团队可以更聚焦业务逻辑,提升研发效率,快速交付系统。
  • 将技术层抽象到云原生层,技术组件的更新换代对业务架构透明,可以更快的进行技术换代而不影响业务架构。
  • 抽象的云原生层持续的组件服务演进,可以提供更好可用性,稳定性的基础设施。
  • 在资源利用率上,实现弹性伸缩,优化资源成本。
  • 衔接标准的CI/CD流程,持续交付软件。

工程师的价值

  • 拓宽技术视野,避免闭门造车。
  • 将掌握技能更好的发挥价值。
  • 输出优质组件,提供到云端,有更大的影响力。

云原生如何落地

可以基于公有云或私有云平台,通过云平台,云中间件,面向微服务,容器编排调度,及Devops流程优化等关键字进行整合,提升业务团队研发效率和质量,帮助业务降低风险,实现更快的交付。

传统的软件架构,不管是单体的还是SOA的架构,在整体架构设计上有很大一部分是趋同的,从上至下:

  • 用户层:pc / app / h5 等
  • 接入层:sso,wns,tgw等
  • 逻辑层:应用逻辑模块,订单,商品,配送,门店,供应链,营销等
  • 基础工具层:数据同步,数据中心,订单一致性,消息系统,音视频编解码
  • 存储层:IDC,Redis,DB等
  • 通用支撑层:支持端到端的监控,代码审计管理,数据统计可视化,监控告警,部署发布流程,自动化测试平台等

我们想一下,对以上通用常见的软件架构如何演化上云呢,存在哪些问题呢?

  1. 架构插件化设计不够,如果换了一个数据上报组件,所有服务都需要调整代码再进行发布。
  2. 历史原因,很多系统技术栈并不统一,一些内部RPC有多种协议,导致组件适配成本增加。
  3. 业务系统底层服务和业务逻辑耦合严重,导致对于服务组件复用困难,需要重复开发。
  4. 研发流程上,需要过多人工环节,会导致流程不规范。
  5. 一些技术公共组件,如视频流加解密,消息推送,监控告警等,需要做到对业务高度透明化。
  6. 容器化程度低,需要在虚拟机或物理机上消耗较多无意义的时间,比如扩缩容,权限审批等。
  7. 监控告警体系不完善,不便捷,如果调用链,日志系统不完善很难具体定位线上问题。

针对以上问题,我们可以得出云原生架构演进方向和需要提升的点。聚焦于微服务,中间件,DevOps这三个方向,结合云弹性来推动架构演进。

优化微服务架构

建立服务开发规范,向云原生靠齐。主要原则遵循云原生12要素。

  • 一份基准代码,多分部署。
  • 显示生命依赖关系。
  • 将配置存储在环境变量。
  • 服务应作为松耦合后端资源。
  • 严格分离构建流程和运行流程。
  • 服务需向无状态进程演进。
  • 通过端口绑定对外服务。
  • 可通过水平扩展实现规模高并发。
  • 可快速启动服务并可优雅关闭。
  • 尽可能保证开发,测试,发布环境一致等价。
  • 使用原创日志流处理。
  • 后台管理任务当作一次性进程运行。
  • 设计出合理且兼容的API是首要任务。
  • 可以过滤测试和应用状态。
  • 采用OAuth2.0和RBAC授权实现应用安全。

云原生开发规范

  1. 统计的技术栈,包括语言,协议,开发框架等
  2. 外部只能通过ApiGateway才能访问
  3. 服务间只能通过RPC或消息队列通信
  4. 服务无状态,可以快速启动或关闭
  5. 框架对同类组件可插拔,更换具体组件不改变服务代码
  6. 基于代码生成器自动代码生成,基于Ci实现自动化交付与部署
  7. 尽量走远端配置,修改配置不用发布或重启服务
  8. 数据库,缓存组件按具体业务实现多租户访问
  1. 架构调整上,很重要的一点是在接入层,统一ApiGateway,对接多端协议,转换为内部微服务协议,可以对API生命周期管理,限流,鉴权等统一管理。
  2. 逻辑层按业务划分,打薄到只有业务逻辑。
  3. 通用逻辑继续下沉,下沉到中台层,沉淀如评论,IM,CRM,搜索,UGC,Push系统,订单,商品,支付,结算等通用逻辑。研发同学可以对这部分业务更深挖,更沉淀。
  4. 再之下为容器层,将原有的二进制服务变为交付镜像。
  5. 中间件层使用通用的云上中间件。
  6. 通用逻辑监控告警,CICD打穿整个交付周期。

在完成了一些列的标准指定,架构演进,上云的流程需要有一个明确的迁移计划:

借助一些工具看数据迁移的效果与质量,比如数据异构,关系数据库与缓存中间件,数据库binlog解析实现增量数据订阅与消费,数据不停机迁移,业务影响最小化。

最后是完善Devops工具链,打通git,jenkins,k8s整个流程。

监控告警,对每层监控指标进行完善,生成调用链及图谱:

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2020-02-02,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 春哥talk 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
消息队列 TDMQ
消息队列 TDMQ (Tencent Distributed Message Queue)是腾讯基于 Apache Pulsar 自研的一个云原生消息中间件系列,其中包含兼容Pulsar、RabbitMQ、RocketMQ 等协议的消息队列子产品,得益于其底层计算与存储分离的架构,TDMQ 具备良好的弹性伸缩以及故障恢复能力。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档