分类 架构 下的文章

亲测推荐 2021 年 SaaS 技术栈:Docker、Django、Traefik 和 IntercoolerJS

我最近发布了个人对Django做为一款优秀应用框架的一些考虑。本文基于此从架构角度做进一步扩展,介绍从开发到生产环境的整体技术栈考虑。

2018 年至今,我一直使用该技术栈构建一些小型 SaaS 应用。

本文最初发布于 www.simplecto.com,经原作者授权,由 InfoQ 翻译并分享。

整体技术栈

随处部署的 Linux 服务器和虚拟机:我使用了 Azure、Digital Ocean 和 Scaleway,并计划在 2021 年将所有部署迁移到Hetzner提供的专用服务器上。

Docker:就是我们常用的 Docker.

Traefik:使用 LetsEncrypt 证书的反向代理和 TLS。

Postgresql:运行在 Docker 中的数据库。

Django:同样运行在容器中。

IntercoolerJS:提供平滑易用的类 Ajax 前端应用支持。Intercooler 的创作者在 2021 年发布了HTMX,是 IntercoolerJS 的更新换代。

Sentry:捕获生产环境中软件缺陷。只需在配置文件中添加几行配置。

Bitbucket Pipelines 替代 CI/CD:鉴于 CI/CD 引入了过多繁琐无用的工具,我在 2021 年不再对个人项目考虑 CI/CD。

ZeroTier:实现 VPN 和控制层。

我在开发小型项目时,采用本地 Docker 容器运行测试,进而直接推送到生产环境。我不考虑使用繁琐的 CI/CD,而是选择了 Bitbucket Pipelines。

7597a5b78ab8a92a0bfadb3fecdfc653.jpeg

上图给出了我所采用技术栈的概览,图中有很多需要详细展开阐述的部分。下面换成列表方式展示。

  • 虚拟机
  • Docker
  • Django
  • 挂载数据磁盘卷
  • 使用长时间运行 Django 命令做为 Workers
  • 挂载数据磁盘卷
  • Postgres
  • 挂载数据磁盘卷
  • Traefik
  • Zero-Tier
  • SSH

托管环境

即便是无服务器架构,也需要一个云服务托管环境。我个人推荐Azure、Digital Ocean和Scaleway。每家都为计算、联网、存储和基本服务提供了充分的选项,支持用户任何构建需求。

同样推荐Hetzner,它提供了各服务层级的硬件、服务和价格。

虚拟机

一些企业应用和个人副业(side projects),并不需要同时为成千上万的用户提供 TB 级数据服务,因此可扩展性并非主要关注问题。对于此,我们可选用最小托管服务选项,通常不高于每月 20 美元。即便是服务价格相对最贵的 Azure,也可选用 Burstable 服务质量的虚拟机。个人推荐Scaleway的开发层级服务器。

注意:在我的技术栈中并没有 Kubernetes,因为我并未考虑可扩展性。

Docker

为确保新的虚拟机运行在最新版 Docker 上,我并没有依赖操作系统本身,而是使用了 curl|bash 方式,即:

curl -s https://get.docker.com | sudo bash

运行上面一行命令,就能获取最适用于当前运行环境的最新版本。

Traefik 实现反向代理

Traefik 对我简直是天赐之选。尽管 Nginx 也很强大,但其并非针对 Docker 环境构建。Traefik 的两个杀手级特性,为我节省了大量时间:

使用 LetsEncrypt 实现自动 TLS。简而言之,一旦设置,无需操心。结合适用的 API 和 DNS 服务提供商,还可以使用 DNS 验证。

使用 Docker label 实现无需重新加载的自动配置。一旦新服务发布,Traefik 通过监听所有 Docker 相关服务而自动发现更改。这使得服务的添加、移除和合并非常方便,不存在任何麻烦。

我对 Traefik 唯一意见是学习曲线略为陡峭。用户必须自行确定如何进行配置,包括配置文件、命令行选项、YAML、Docker label,乃至组合使用。

提示:我发布了自己使用的Traefik生产环境配置文件,供参考。

Postgres 数据库

亲测推荐,PostgreSQL 从不会令我失望。PostgreSQL 容器可毫无问题地添加到任何项目中。我只需简单地启动容器,绑定端口,挂接数据卷到主机磁盘,仅此足矣。

docker-compose.yml
version: '3.1'


services:


  db:
    container_name: postgres
    hostname: postgres
    image: postgres:11
    restart: always
    environment:
      POSTGRES_PASSWORD: secretsonly
    volumes:
      - ./data:/var/lib/postgresql/data
    ports:
      - 5432:5432
    networks:
      - web


networks:
    web:
        external: tr

用于 Web 的容器化 Django

Django 很好地支持发布到容器中,我多年以来一直这么用。我反复强调开发环境和生产环境匹配的重要性,Docker 为我实现了一切。

我在 2021 年新推出了一个 Django 项目,用做新项目的模板,参见https://github.com/simplecto/django-reference-implementation。

实现异步任务的 Django 命令

我使用做为标准框架组成的自定义Django命令实现异步任务。该模式采用具有 sleep()的 while 循环,轮询数据库相关操作,并采取相应的动作。

截止 2021 年,我已使用这一模式运行一个网站截屏项目一年多,回报丰厚。该项目每日对 1500 个网站做截屏,所有操作由 Django 命令计划和管理。项目地址:https://github.com/simplecto/screenshots。

IntercoolerJS 降低了复杂性

这里如果展开说,需推出多个帖子,恐怕内容太长,以至于不会有人愿意读。我结合 JQuery 和这个小型 JavaScript 库,实现部分类似单页应用的效果,尽管事实上并非单页应用。

IntercoolerJS 保留了 Ajax 的传统优点,从后端 HTML 更新 DOM,无缝且平滑,非常便于实现用户登录和更新小型表单等元素。

强力推荐访问IntercoolerJS官网。

其创立者在 2021 年继承发展了 IntercoolerJS,推出了HTMX。

Sentry 捕获生产中错误

任何应用都会出错,但不应向用户展示。Sentry 提供了一种捕获生产中软件缺陷的易用便捷方式,其特性包括:

开源许可,可在生产中任意部署。

只需在 Django 项目的 settings.py 中添加几行配置,即可生效。

与 Git 代码库和问题追踪系统紧密集成,提供全生产环境的缺陷可追踪能力。

另一个优点是,随时能在生产环境中禁用。

更多信息,可访问Sentry官网。

Bitbucket Pipelines 替代 CI/CD

2021 年,我不在个人项目的部署中使用 CI/CD。其中存在太多工具,复杂性高。我只是使用 PyCharm 运行测试,然后从开发设备直接交付生产环境。

当前存在多种 CI/CD 解决方案,但是我推荐 Bitbucket 提供的 Pipelines 的服务。该服务每月提供数百分钟的免费使用,只需很少费用就能提供自上而下的功能。我自己在使用中很少碰到问题,很喜欢它们的 YAML 配置文件。

我使用 bitbucket-pipelines.yml 文件,实现跨多个 Docker 容器的完全端到端测试,加载数据库,并在几分钟内执行数以百计的测试。该服务是我们团队高效的关键,支持生产环境中每日五次以上 Push。

更多信息,访问Bitbucket官网。

ZeroTier 实现 VPN

最后,推荐一种在很大程度上是可选的、但是最好应具备的技术。Zerotier 是一种独树一帜的网络/VPN 服务,我用其连接所有的个人计算机。它可穿透防火墙联通家庭和办公场所,一分钟即可配置好。

如果所有设备使用 ZeroTier,就可以避免 SSH 中令人头疼的密钥管理,单机上共享带宽。

Zerotier 可运行在 Linux、Mac、Windows、Android 和 iPhone 上,覆盖大部分设备。

ZeroTier 的一个问题在于,我并不完全了解它的工作机制。和 MacOS 和 iPhone 类似,它们会按用户期望工作,并不出问题,只是从用户体验角度看有些不爽。但对于一名 CTO,谁又会去关心具体的细节呢?

总结

希望上面的深入介绍能激发读者对 Docker、Django、Traefik,尤其是 IntercoolerJS 的兴趣。它们简单、易于使用,能在适当时大展身手。

原文链接: Docker, Django, Traefik, and IntercoolerJS is My Go-To Stack for Building a SaaS in 2021
https://www.infoq.cn/article/W4leI4XZ32eSTqFJ8qPl

我成功开发了一个 SaaS 项目,技术栈是这样的

作为一名忠于内心的工程师,每当我看到一家公司发布有关它们技术栈的文章时,我都会泡一杯咖啡,坐下来耐心阅读,看看有没有新的发现。了解其他公司业务背后隐藏的一些技术十分有趣。就像娱乐八卦一样,只不过这是技术层面的探索。

几个月前,我开始开发另一个 SaaS,该项目经历无数次迭代。幸运的是,尽管项目仍处于早期阶段,但是很多网站已经对其进行了集成。

作为一个自负盈亏的独立创业者,我相信正是由于专注于自动化,才让我能为来自 80 多个国家和地区的客户提供可靠服务,并且每周持续提供新功能。当我想要了解服务的运行情况或者其他方面的信息时,我会尝试利用我熟悉的工具。当然,我也明白,在一些特殊情况下这些工具并不会帮到我。

现在,我简要地介绍下平时使用的一些工具。

非常重要的一点是,虽然工具列表看起来很长,并且有一些是非常规且不常用的选项,但实际上我在基础架构上花费的时间很少,如果有的话,每个月平均下来也就是几个小时。还有一点就是个人推荐就像是开处方一样,我认为对我非常有用的一些工具,可能并不适合你。一定要考虑自己的实际情况,并利用好当下你熟悉的工具。

编程语言

多年来,我学习和使用过好几种编程语言,但是对于独立项目,我特别挑选出两种编程语言。这两种编程语言可以在生产力以及可靠性上取得很好的平衡。

Python:很多项目的后端代码都是用 Python 实现的。它可以让我能够以较快的速度发布新功能。另外,我使用 mypy 用于类型提示,这方便我进行代码管理。

Typescript:我以前会有意地避开前端开发的工作。直到大约 4 年前,我发现并开始使用 Typescript。它让我感觉写前端的工作体验更好了,现在我使用它并结合 React 框架一起构建我的项目。

框架

理论上,我会在这里介绍很多这方面的内容,但是相关论坛上有不少介绍,我也是站在巨人的肩膀上学到很多知识。因此我只想介绍几个非常不错的框架:

Django:该框架简直就是独立开发者的宝库。你在该行业中工作的时间越长,你越能体会到避免重复造轮子带来的幸福感。这一框架可以让你走的更远,因为它的功能实在是太全面了,应用场景也很广泛。推荐阅读Instagram如何优化Python提高服务性能、Sentry项目、10大Django构建的网站了解一下 Django 的使用场景。对我来说,该框架不管在性能还是功能方面都能满足我的需求。

React:数据展示相关的 Web 应用是使用 React + Webpack 构建的。在长时间使用 Angular 后,我最终切换到 React,因为它是支持可插拔的视图层,不会对其他功能造成影响。我使用性能表现不错的django-react-templatetags将 React 组件嵌入到我的 Django 模板中。

NextJS:我使用它进行页面、文档等的加载。它让我能重用各种 React 组件,并且可以提高静态页面的性能以及 SEO 优势。

Celery:我使用该框架用于后台/定时任务的管理。该框架的学习成本较高,但是一旦你了解了它的工作原理,并应用到项目中后,你就能体会到该框架的稳定性和可靠性了。

Bootstrap 4:我基于 Bootstrap 构建前端应用。它节省了我很多时间,并且文档资料详细丰富。这就是我选择使用它的原因。

数据库

我最初将所有数据都存储在 SQLite 数据库中,对数据进行备份意味着要将副本数据复制到 S3 之类的对象存储中。之前对于测试过的一些小型站点来说,没有什么问题。但是,随着项目的功能及页面越来越多,我需要更多专门的数据库来支持这些功能:

Clickhouse:我相信 Clickhouse 是为数不多的随着时间的推移而经久不衰的技术之一。说实话,这是一款十分给力的数据库,它能够实现原先在低配置硬件上几乎无法实现的功能。

PostgreSQL:我必用的关系数据库。默认配置合理,经历了充分的市场检验并且与 Django 深度集成。在 Panelbear 中,PostgreSQL 主要用于与分析无关的应用数据存储;对于分析用的数据,我使用 Django 实现了一个简单的接口从 Clickhouse 查询数据。

Redis:我在很多场景中使用了 Redis,比如缓存、速度限制、任务队列以及作为有生命周期的键值存储。Redis 功能强大且性能稳定,社区文档也十分丰富。

部署工具

与这篇文章描述的一样,我不会将我的基础设施视为宝贝一样对待。服务器和集群本来就是一个工具而已。所以如果某一台服务器出现问题,用另外一台正常的服务器替换一下就好了。这意味着所有的操作在 git 仓库中被描述为代码逻辑,并且我不会通过 SSH 登陆服务器进行一些操作。你可以将这个描述视为一个模板,可以通过一个命令将整个基础架构克隆到任何的 AWS 服务中。

这在灾难恢复时也会对我有所帮助。我只需要运行一些命令,几分钟后,我的应用服务就可以重建并能正常运行了。当我将应用从 DigitalOcean 迁移到 Linode,以及最近往 AWS 迁移时非常有用。所有的操作都通过代码描述和执行。因此,即使在几年后,我也很容易的跟踪项目的相关部署和运行情况。现在所有的公司都拥有 AWS IAM 策略或者 VPC 子网,这些都是通过一些 UI 界面点击操作完成的,现在所有人都离不开这一功能,因为确实给用户带来了很多便利。

Terraform:我使用 Terraform 来管理大部分云基础架构。在我的 Terraform 清单中声明了诸如 EKS 集群、S3 存储、角色和 RDS 实例之类的一些配置。这些数据会同步到另外的加密 S3 存储,以避免我开发用的笔记本电脑发生故障而无力回天。

Docker:我会将所有服务构建为 Docker 映像。甚至有状态的组件(比如 Clickhouse 或 Redis)也作为 Docker 容器打包并运行在我的集群中。这也让我的应用服务可移植性非常高,因为我可以在能够运行 Docker 的任何地方运行它。

Kubernetes:它极大地解放了我繁琐的工作。我并不是盲目地向所有人进行推荐,因为在工作的这些年里,我使用它解决了好几次大型的生产故障。为公司及时解决生产问题,让我感觉十分自豪。我还用它进行容器化应用的管理,这也帮我减轻了工作负担。

GitHub Actions:过去,我常常使用的是CircleCI(这个用起来也不错),但是对于这个项目,我更喜欢使用 GitHub Actions,因为它删除了需要访问代码库以及部署密码的一个不必要的服务。但是,CircleCI 同样具有很多不错的功能,我仍然向大家推荐它。

基础设施服务

我从最开始使用月费 5 美元的 DigitalOcean 单实例服务器开始,逐步转向使用 Kubernetes 来管理服务,因为我正在彻底改变 Kubernetes 提供的一些开箱即用的功能(比如:服务发现、TLS 认证、负载均衡、日志滚动管理、滚动发布、容量管理等)。

但是,即使在较大的服务器实例上,使用 Kubernetes 管理的 DigitalOcean 也同样存在可靠性问题。集群 API 服务经常会随机地停止工作并且无法恢复,这会破坏包括负载均衡在内的许多集群服务,也就意味着服务停机无法对外提供正常服务。每当发生这种情况时,我会重新创建一个新的集群,尽管使用 Terraform 可以很轻松的实现,但是这并不会增加大家对其托管服务可靠性的信心。我怀疑是他们的资源不是特别充足导致的,考虑到他们的服务收费较低,因此这是可以理解的。

不幸的是,几周后,我就无法解决上面提到的问题了。这就是为什么我决定迁移到Linode的原因,在接下来的一个半月的时间里,系统再也没有出现过任何问题。

但是,AWS 向我抛来了更加诱人的优惠,所以我最近又做了一次迁移。AWS 还支持使用托管服务比如 RDS 来减轻 PostgreSQL 的压力,这对我来讲是个很大的优势。我的迁移工作没有那么复杂,因为我的所有基础架构都是通过 Terraform 和 Kubernetes 配置清单进行描述的。系统迁移可能会花费或长或短的时间,所以一定要有耐心。这一方面的话题可以在其他文章中找到。

AWS:提供可预测服务以及大量的托管服务。我主要在全职工作的时候使用过它,所以我没有花费很多时间来处理问题。我使用过的 AWS 服务主要有 EKS、ELB、S3、RDS、IAM 以及专用 VPC,未来我可能会使用 Cloudfront 和 Kinesis 服务。

Cloudflare:我主要将其用于 DDoS 保护、DNS 服务以及负载各种静态资源的边缘缓存(目前减少了 AWS 的 80%网络出口带宽费用——它们的带宽定价是在是太贵了!)。

Let’s Encrypt:免费的 SSL 证书授权服务。我在 Kubernetes 集群中使用了 cert-manager,它根据我的入口规则自动颁发和更新证书。

Namecheap:我常常使用的域名注册服务商。它允许 MFA 登录,这是一个十分重要的安全功能。与其他域名服务商不同,它们不会每隔几年就会突然增加域名的高昂续费费用,十分的良心。

Kubernetes 组件
以下组件可以自动完成大部分开发运维工作。我也使用其他的一些组件,但是我最想推荐给大家的是下面几个:

ingress-nginx:一个性能稳定的使用 NGINX 作为反向代理和负载均衡的网络入口控制器,控制入口流量到集群节点的网络流量负载均衡。

cert-manager:该组件可以按照入口规则中的定义自动颁发和更新 TLS 证书。

external-dns:借助 DNS 服务(例如 Cloudflare)同步公开 Kubernetes 服务和网络入口。

prometheus-operator:可以自动监控大部分的服务,并可以通过 Grafana 对数据进行展示。

flux:可以实现在 Kubernetes 中进行连续交付。当我要发布新的 Docker 映像时,可以通过拉取镜像进行部署。

命令行工具

我使用的命令行工具有很多,但经常使用且值得推荐的就下面这几个:

kubectl:与 Kubernetes 集群进行交互的工具,可以对日志、pod 和服务进行监控,并且可以 SSH 登陆到运行中的容器。

stern:Kubernetes 的 pod 日志查看工具,方便易用。

htop:交互式系统进程查看工具,真的比系统自带的 top 工具好用。

cURL:网络请求工具,可以对请求头进行检查。

HTTPie:与 cURL 工具类似,但是对于 JSON API 而言更简单易用。

hey:网络负载测试工具,可以提供详细的延迟分布报告。

监控工具

Prometheus:可以高效地存储时间序列数据并进行监控。可以追踪所有群集和应用程序的性能指标。比使用 Cloudwatch 进行应用程序监控要便宜得多。

Grafana:可以对 Prometheus 监控数据进行展示。所有的展示数据以 JSON 文件进行描述,并在 git 仓库中进行版本控制。

Sentry:对应用程序异常情况进行监控。该工具在发现带有其他元数据的未处理错误时进行告警通知。

Loki:受 Prometheus 启发而发展出来的一款日志聚合系统。它附带了 prometheus-operator 功能,可以帮助我在整个群集中对海量日志进行搜索。

邮件工具

Fastmail:我优先选用的商务电子邮箱,功能齐全且稳定性高。

Postmark:我主要将其用于交易电子邮件(电子邮件验证、每周报告、登录安全警报、密码重置等)的收发。他们的电子邮件传输速度非常快,邮件移动应用程序在业界也是一流的。

开发工具

GitHub:源代码托管及版本控制工具。

PyCharm:可能是 Python 最好的 IDE 工具。使用它可以轻松地重构和导航整个项目代码,而不仅仅是单个代码文件。 即使使用大型动态代码库,该工具的使用表现也很好。

VS Code:非常适合 Typescript / React 编程,并且可以用作通用代码编辑器。

Poetry:Python 打包及有锁文件的依赖管理工具。

Yarn:具有本地缓存的快速 JS 依赖项管理工具。

Invoked:我使用它将所有代码库任务包装在可调用的命令中。例如,使用inv build可以准备静态资源,打包前端/后端环境依赖,并生成 docker 映像。这样,就可以在本地执行与 CI 运行的相同的命令。

其他工具

Panelbear:当然,除了 Panelbear,还有什么能比 Panelbear 更好的工具来跟踪 Panelbear 的网站分析呢?内部测试是有很大收益的,因为我就是我自己的客户。

Healthchecks.io:当计划作业未能正常运行时,就会通过电子邮件或者 whatsapp 通知到我。它也是基于 SaaS 的辅助程序,这个工具我使用了好几年了,非常高兴可以推荐给大家。

Trello:我使用它来记录和跟踪一些问题、需求及想法等等。

Figma:用于为目标页面快速制作模型、横幅和插图,它取代了Sketch作为我的入门工具。

原文链接

https://panelbear.com/blog/tech-stack/

说实话,去一家小公司从 0 到 1 搭建后端架构,真难~

  1. MVC
  2. 服务拆分
  3. 微服务架构
  4. 领域驱动设计

总结

来腾讯之前在前公司做了3年的后端开发, 经历一款SaaS产品从0到10(还没有到100, 哈哈哈)的过程, 3年间后端的架构逐步演变, 在微服务的实践过程中遇到的问题也越来越多, 在这里总结下.

产品是一款服务于人力资源的SaaS在线服务, 面向HR有Web Android/iOS 小程序多个客户端, 后端采用RESTful风格API来提供服务. 主要使用Python语言, 方便快速迭代.

架构的演进经历了4个大的阶段: 1. MVC 2. 服务拆分 3. 微服务架构 4. 领域驱动设计.

1. MVC


项目刚开始的时候, 后端同事不超过5个, 这个阶段主要的工作是实现产品的原型, 没有太多的考虑架构, 使用Django来快速实现功能, DB的表结构设计好之后, 抽象出功能View, 由于产品设计也很不完善, 后端需要很多的预留设计, 避免产品逻辑的变更带来整个表结构的变动, 在这个阶段代码上最重要的是确定适合团队的代码规范, 代码检查规则.

1.jpg

整体上架构如上图, Nginx负责负载均衡, 分发流量到多个Django服务, Django处理逻辑, 需要异步任务就交给Celery, 然后数据量比较大的地方使用Redis做缓存. 同时还有实时消息通知的需要使用了Nginx Push Module.

问题与优化方式:

  1. Django并发性能差 使用uWSGI Master+Worker 配合 gevent 携程支持高并发
  2. Redis连接数过多 使用redis-py自带的连接池来实现连接复用
  3. MySQL连接数过多 使用djorm-ext-pool连接池复用连接
  4. Celery配置gevent支持并发任务

随着开发的功能越来越多, Django下的app也越来越多, 这就带了发布上的不方便, 每次发布版本都需要重启所有的Django服务, 如果发布遇到问题, 只能加班解决了. 而且单个Django工程下的代码量也越来越多, 不好维护.

2. 服务拆分


随着后端团队的壮大, 分给每个同事的需求也越来越细, 如果继续在一个工程里面开发所有的代码, 维护起来的代价太高, 而我们的上一个架构中在Django里面已经按模块划分了一个个app, app内高类聚, app之间低耦合, 这就为服务的拆分带来了便利. 拆分的过程没有遇到太大的问题, 初期的拆分只是代码的分离, 把公用的代码抽离出来实现一个公用的Python库, 数据库, Redis还是共用, 随着负载的增加, 数据库也做了多实例.

2.jpg

如上图, 服务之间尽量避免相互调用, 需要交互的地方采用http请求的方式, 内网的调用使用hosts指向内网地址.

问题与优化方式:

Nginx Push Module由于长时间没有维护, 长连接最大数量不够, 使用Tornado + ZeroMQ实现了tormq服务来支撑消息通知
服务之间的调用采用http的方式, 并且要求有依赖的服务主机配置hosts指向被调用的地址, 这样带来的维护上的不方便. 以及在调用链的过程中没有重试, 错误处理, 限流等等的策略, 导致服务可用性差. 随着业务拆分, 继续使用Nginx维护配置非常麻烦, 经常因为修改Nginx的配置引发调用错误. 每一个服务都有一个完整的认证过程, 认证又依赖于用户中心的数据库, 修改认证时需要重新发布多个服务.

3. 微服务架构


3.jpg

首先是在接入层引入了基于OpenResty的Kong API Gateway, 定制实现了认证, 限流等插件. 在接入层承接并剥离了应用层公共的认证, 限流等功能. 在发布新的服务时, 发布脚本中调用Kong admin api注册服务地址到Kong, 并加载api需要使用插件.

为了解决相互调用的问题, 维护了一个基于gevent+msgpack的RPC服务框架doge, 借助于etcd做服务治理, 并在rpc客户端实现了限流, 高可用, 负载均衡这些功能.

在这个阶段最难的技术选型, 开源的API网关大多用Golang与OpenResty(lua)实现, 为了应对我们业务的需要还要做定制. 前期花了1个月时间学习OpenResty与Golang, 并使用OpenResty实现了一个短网址服务shorturl用在业务中. 最终选择Kong是基于Lua发布的便利性, Kong的开箱即用以及插件开发比较容易. 性能的考量倒不是最重要的, 为了支撑更多的并发, 还使用了云平台提供的LB服务分发流量到2台Kong服务器组成的集群. 集群之间自动同步配置.

饿了么维护一个纯Python实现的thrift协议框架thriftpy, 并提供很多配套的工具, 如果团队足够大, 这一套RPC方案其实是合适的, 但是我们的团队人手不足, 水平参差不齐, 很难推广这一整套学习成本高昂的方案. 最终我们开发了类Duboo的RPC框架doge, 代码主要参考了weibo开源的motan.

4. 领域驱动设计


4.jpg

在这一架构中我们尝试从应用服务中抽离出数据服务层, 每一个数据服务包含一个或多个界限上下文, 界限上下文类只有一个聚合根来暴露出RPC调用的方法. 数据服务不依赖于应用服务, 应用服务可以依赖多个数据服务. 有了数据服务层, 应用就解耦了相互之间的依赖, 高层服务只依赖于底层服务.

在我离职时领域驱动设计还在学习设计阶段, 还没有落地, 但是我相信前公司的后端架构一定会往这个方向继续演进.

总结
架构的设计, 技术的选型, 不能完全按照流行的技术走, 最终还是服务于产品, 服务于客户的需求. 设计过程中由于团队, 人员的结构问题, 有很多的妥协之处, 如何在妥协中找到最优解才是最大的挑战.

Service Mesh这种新一代的微服务架构正在成为主流, 虽然现在的工作与微服务无关了, 但是也还会继续关注学习.

企业上云:选型,策略,架构,实践

1概述

2018年8月,工业和信息化部印发《推动企业上云实施指南(2018-2020年)》,提出到2020年行业企业上云意识和积极性明显提高,上云比例和应用深度显著提升,云计算在企业生产、经营、管理中的应用广泛普及,全国新增上云企业100万家,形成典型标杆应用案例100个以上,形成一批有影响力、带动力的云平台和企业上云体验中心。鼓励各地加快推动开展云上创新创业,支持各类企业和创业者以云计算平台为基础,利用大数据、物联网、人工智能、区块链等新技术,积极培育新业态、新模式。

随着云计算的蓬勃发展,各个企业开始纷纷入云,但是在入云的道路上各自不同,根据企业的规模、技术特点、保密性的要求等,可选择的有公有云、私有云、行业云、混合云、集团云等等。

本文主要讲企业在上云的过程中的一些要点,从为什么要上云、怎么上云、都有哪些考虑点、云上有什么样的技术,最后提供了上云实践的必要过程。

2为什么要上云?

企业的基础架构从传统的烟囱式部署专项云端部署,基于云计算平台的解决方案,已经成为企业管理者满足其业务战略的需求,快速实现其收益和效率的最聪明和最无缝的方式。

云计算服务为公司提供了巨大的优势和工作量转移:IT部门不再需要购买、部署和维护内部的计算硬件和软件,可以通过云服务快速、容易地建立起来,无需IT人员参与就能根据需要进行扩展,并且会自动更新到最新版本。简而言之,云计算极大地简化和降低了IT服务提供的复杂性和成本。数字经济已经成为发展趋势,各企业都在进行或准备进行数字化转型,而上云则是企业数字化转型的起点。

企业上云,主要有以下几点原因:

■ 降低成本。企业运营需要成本,IT基础设施投入也是成本,大企业为了降低成本,提高集约化效果,形成企业内部或者集团内部的私有云、集团云;中小企业为了降低成本,选择公有云或者行业云、混合云;微型企业,无需投入建设机房、购买IT设备的资金,直接用公有云服务商提供的公有云服务。使用云计算服务,比购买一般的物理硬件要便宜得多,那么小微企业就可以摆脱很多不必要的开支。

■ 高效弹性,灵活扩展。满足弹性、快速供给、快速释放的IT基础设施能力,才能更好的为业务服务。效率是企业的生命线,只有提高了生产率,企业才能在市场竞争中生存,云是提高IT基础设施效率的非常好的手段。

■ 使云端数据更有价值。云带来了更大的灵活性和移动性,使用云,可以让企业在一台机器上开始工作并且在另外一台机器上完成它;企业对于庞大的交易、管理等数据做大数据分析,提供精准营销、分级客户管理等服务,使数据增值;人工智能更是基于大数据为基础,提供更加高阶的场景化服务。

■ IT部门从成本中心转向利润中心。云的未来,不是一个成本中心,而是一个利润中心,它能创新很多新的业务模式,成为企业新的利润增长点。

3上云的难点分析

大中型企业的IT基础设施,一般都有比较重的历史包袱,如应用系统为部门级而非企业级、数据割裂且格式不统一、烟囱式部署架构、无法按需扩展等等,因此企业上云,主要有以下几个难点:

■ 云化架构转型,需要建立相应的组织架构及人才队伍。从上层管理层到中层及下层技术人员,都要首先从意识形态上接收并主动拥抱云,理解云的架构、云的特点,建立起适合云计算发展的组织架构,培养响应的人才队伍,才能更好的做云化转型;

■ 原有的IT架构,难以向云端迁移。云大多以虚拟化、开源技术、分布式技术为主,而原有的大多使用了大型机或小型机、相对重量级的中间件和数据库、以闭源厂商的产品为准,因此无法把现有的系统直接搬上云,必须要做云化改造;

■ 原有系统复杂,系统需要重构。由于历史的原因所建立的系统必须要做重构,采用云化架构,使用适合云部署的技术,如虚拟化、容器化、微服务化,同时基础设施要建立相应的计算、网络、存储等资源池,采用计算虚拟化、软件定义存储SDS、软件定义网络SDN等技术、容器Docker等技术,提供IAAS、PAAS、SAAS、CAAS等云服务。

4上云的方向选择

企业上云,根据自身的特点,选择上云的方向,既要满足监管的要求、企业的需求,也要考虑自身能力,切不可能盲目跟风,选择与自身实力不匹配的方向,可以从以下几点考虑:

■ 大中型企业。这类企业自身盈利能力较强,抗风险能力较高,IT基础设施投入较大,一般都会选择自建私有云,同时会考虑输出部分云计算能力给其他中小微企业使用,如某国有银行,不但建有内部使用的私有云,还有为集团、分行、子公司及外部客户使用的公有云,通过建信金融科技公司,提供从上到下的IAAS、PAAS、SAAS全套金融云服务;

■ 小型企业。这类企业因自身规模没有大中型企业大,IT基础设施投入相对要小,可以选择混合云或者行业云,自身因为数据保密的要求,将核心关键的系统建立在私有云中,对于不关键的系统可以使用公有云或行业云,以此降低IT投入成本。

■ 微型企业。这类企业对于成本比较敏感,IT投入比较小,不会将能力过多的投入到IT建设中,可以选择部署在比较好的行业云或者公有云,甚至完全托管在其上,将精力聚焦在业务发展上,用最小的成本承载更多的业务。

■ 监管要求明确的企业。这类企业一般都属于特点比较明显的行业,比如银行、证券、保险等,有银保监会、证监会监管,对于系统的高可用级别、灾备能力、数据安全等有比较高的要求,需要按照监管机构的要求,使用安全等保三级及以上的云。

5上云的策略

企业上云分为基础设施上云、业务系统上云和基础平台上云,在本文中主要以基础设施上云为主论述。

5.1基础设施上云

企业的IT基础设施主要包括机房、计算设备、存储设备、网络设备以及一些配套的安全(如DDOS、IDS等)、终端等,上云最主要解决的就是在这些领域都采用什么技术、怎么实现云化基础设施。

■ 计算领域:可以采用vmware、kvm、xen、PowerVM等虚拟化技术以及docker等容器技术,提供IAAS、PAAS的服务。

■ 存储领域:可以采用ceph等开源技术以及众多厂商提供的如vsan、FusionStorage等分布式存储技术,实现软件定义存储SDS、

■ 网络领域:可以采用NFV、SDN等技术实现软件定义网络。

■ 办公终端领域:可以采用ctrix等桌面虚拟化实现桌面的云化管理。

5.2业务系统上云

企业的业务系统在上云时不一定要齐步走一起上云,需要分批分步骤根据实际情况一步一步上云,分几种策略:

■ 从外围到核心。先从外围系统不重要的管理办公类系统着手,做系统改造或者重构后上云,比如人力资源管理、办公OA、MAIL、考勤、日志管理等系统;其次选择重要性低的一般交易性系统,如渠道类的网站、机构管理、监控、呼叫中心等;最后选择核心交易类的系统,如网银、手机银行、信贷、财务会计、代收代付等系统;

■ 从简单到复杂。先从WEB服务器、应用AP服务器入手,建立专部署WEB、AP的资源池,实现云化部署,再建立云数据库、分布式云数据库,实现数据库云,将所有基础设施实现云化部署;

■ 集中力量从核心到外围。国内也有企业如某国有银行,利用建设新一代核心系统时,集中力量,做企业级建模将核心的业务进行了重构,分三期将除了IBM主机之外所有重要IT系统生产环境搬上了私有云,老系统逐步下线,完成了云化改造。

那么,在上云的过程中,需要考虑哪些应用系统能够上云,哪些系统不上云,简单来说:

重负载、IO高、响应时间要求高的系统不适合上云,笔者所在的企业在做系统搬迁时,ODS(操作型数据存储)系统的AP服务器在物理机上部署时,跑批时TPS可以达到1000左右,但是部署在虚拟化环境后TPS下降到300左右,跑批时间延长3倍左右,已经不能满足业务要求,经查是由于程序在写文件时,直接写盘和写经过vmware文件格式VMFS后磁盘时存在速度上的差异,导致TPS下降,采用物理机直接部署后问题不再重现,于是放弃了上云,还是采用物理机部署。

业务系统上云,不是为了上云而上云,最重要是要能够发挥出云的特点,达到Cloud Native(原生云)的效果,实现CI/CD,devops一体化敏捷管理。要实现系统的敏捷部署、弹性扩展、动态迁移、故障自愈、数据更加安全可靠等,就需要系统在上云前做相应的改造或者开发新的业务系统来代替原业务功能,该如何做呢?主要从以下方面考虑:

■ 新系统可以采用spring cloud等微服务解决方案,基于spring boot等框架,进行微服务改造,做到Cloud Native原生云系统。

■ 系统部署方面,抛出传统的物理机、虚机部署,使用docker等容器等部署,采用主流的PAAS平台,基于kubernetes、mesos、swarm等主流框架,管理容器化的应用,实现开发、测试、运维的devops一体化管理,打通软件研发管理全流程。

5.3基础平台上云

除了基础设施及业务系统,对于一些通用的基础平台,如大数据、区块链、物联网、人工智能都是上云的方向,并且是未来的主流方向之一,不必重复建设复杂而又庞大的平台,直接使用云上的大数据、区块链、物联网、人工智能等服务,更好的为业务服务,开发更多的业务场景,提升资源使用效率,获得更高的利润。

6云计算架构

6.1云计算概述
请输入图片描述

企业上云:选型,策略,架构,实践
云计算在企业架构中主要与IT架构有关,与应用架构、技术架构、安全架构、数据架构都有关系。

下图为IBM CCRA参考架构,定义了构成云计算环境的基本架构元素:

请输入图片描述

请输入图片描述

企业上云:选型,策略,架构,实践
企业上云:选型,策略,架构,实践
云计算架构,有很多种描述,主要是以IBM CCRA模型为基础,每个企业在落地时有不同的特点,在此不赘述。简单来说,云计算是由计算/网络/存储等资源池、云服务、云管理平台、云安全等组件组成的,通过软件定义的方式为客户提供IAAS、PAAS、SAAS、CAAS等云服务。

资源池是基础。资源池是云计算的承载体,主要包括计算、存储、网络等资源 。没有资源池,云服务、云管理是空中楼阁,无法落地。

云管理是平台。云管理平台对所有资源进行统一管理、调度,对资源进行全生命周期的管理。

云服务是核心。将各种资源打包成服务,由云平台调度,为使用者提供服务,主要提供IAAS/PAAS/SAAS等服务

虚拟化、容器等都是资源池的实现技术基础,有了虚拟化、容器技术,可以更方便、快捷的提供IT基础设施服务。

6.2资源池

云计算最基础的是资源池,涵盖计算资源池、存储资源池、网络资源池等,计算资源池又分、X86虚拟化资源池、POWER资源池、Mysql/Redis资源池、大数据资源池、GPU资源池等等,主要有以下几类:

1、X86虚拟化资源池。以vmware esxi、kvm、xen等技术为主,私有云采用vmware较多,公有云及行业云等主要以kvm技术为主;

2、小型机资源池。以PowerVM为主,主要采用Power虚拟化技术;

3、裸金属资源池。为用户提供裸金属服务器,满足部署不适合做虚拟化部署的需求,主要以X86服务器上安装Oracle RAC、Mysql、以及应用软件等;

4、大数据资源池。部署大数据类基础软件,存储、计算大量数据,挖掘数据价值。

序号

资源池类型

主要功能

不适合功能

1

X86虚拟化资源池

Web、Ap

数据库

2

小型机资源池

DB

web

3

裸金属资源池

重载AP、DB

Web

4

大数据资源池

数据分析

Web、ap

6.2.1网络区域规划

资源池需要部署到实际的网络区域中,比如传统的金融企业一般会分为几个区域:

请输入图片描述

企业上云:选型,策略,架构,实践
1、内网业务区。该区域主要部署内部系统的区域,基本上企业核心的系统都在此部署,属于一个功能完备的区域,既有WEB、AP又有DB、大数据等;

2、运行管理区。该区域主要部署保障IT系统运维正常运转的维护管理类系统,如监控、安全审计、批量调度、运维大数据等;

3、互联网DMZ区。该区域主要起到隔离互联网与内部网络的作用,互联网业务请求通过该区域服务器做交易的转发(交易不落地)到内部业务区域做业务处理;

4、外联网DMZ区。该区域和互联网DMZ区起到相同的作用,不同的是所连接是外部合作机构,而不是互联网渠道,相对互联网来说,外联网所连接的机构相对可信一些。

6.2.2资源池架构

云计算最基础的是资源池,涵盖计算资源池、存储资源池、网络资源池等,计算资源池又分、X86虚拟化资源池、POWER资源池、Mysql/Redis资源池、大数据资源池、GPU资源池等等,下面我们以使用最多企业内部使用的私有云X86虚拟化资源池和Power数据库资源池为例,大致说明资源池的架构。

■ X86虚拟化资源池

某企业采用的X86虚拟化资源池,以CDP(云部署单元)为单位,每个资源池可以包含N个CDP,每个CDP包含3个独立的集群,每个集群包含16台X86服务器和1台NAS(做root盘),保证各条通路的相对独立性,避免生产故障蔓延,应用的部署单元以3的倍数部署,保证高可用。这个架构的高可用性是很高的,基本从底层、网络、服务器、板卡、接线等硬件层面到上层的应用部署都考虑到了,运行六七年来未发生过生产事故,资源池物理部署图如下:

请输入图片描述

企业上云:选型,策略,架构,实践
■ Power资源池

Power服务器在企业中使用还是比较广泛的,虽然近年来受到互联网去IOE架构的影响,很多互联网企业甚至一些小的企业不再使用,但是在中大型及一些高可用要求高的小企业中使用还是很广泛的。基于PowerVM虚拟化技术,构建Power资源池,是很多企业采用的策略,尤其是银行、证券等金融行业。

Power资源池提供全面的HA + LPM(在线分区迁移)+ RR(远程重启)+ GDR(容灾)一站式高可用方案,相比传统物理机HA方案增强了高可用,消除了高可用的盲区。

Power资源池是基于企业级高端虚拟化+架构的最佳实践,并非泛指的云平台,可以承载原先小型机、PC服务器平台运行的几乎所有业务,通常建议可用作除关键业务外的大部分数据库及应用的整合平台,有以下的好处:

分配同等虚拟资源情况下,相对与同代Power物理服务器提供相当性能,并通过高端服务器整合提供更高的弹性性能和扩展性;
对于整合旧Unix、PC服务器的场景,提供多倍于原系统的开放平台最高单核性能来加速应用,并提供更大的性能弹性和扩展性;
少数需要极端网络、存储IO吞吐量和响应时间的应用,建议单独评估测试;
典型软件包括数据库、中间件、各类企业软件套件如ERP、自研应用等。Oracle/DB2/WAS/SAP等主流软件都认证PowerVM虚拟化并有大量部署案例。
典型的应用场景示例:银行:除核心、前置等最重要一二十套系统以外的数据库、应用等;政府:除几套关键系统外,其他数据库、中间件服务器整合;企业:ERP、数据库服务器整合。

请输入图片描述

企业上云:选型,策略,架构,实践
6.3云服务

我们常说的云计算的云服务主要分为三种:IAAS、PAAS、SAAS(随着发展衍生出很多种XX即服务,最基础的还是这三类)基础云服务。

6.3.1基础云服务

IaaS: Infrastructure-as-a-Service(基础设施即服务)。提供给消费者的服务是对所有计算基础设施的利用,包括处理CPU、内存、存储、网络和其它基本的计算资源,用户能够部署和运行任意软件,包括操作系统和应用程序。主要指为客户提供安装了最基础的OS的虚机/物理机,提供最基础的计算能力。

PaaS: Platform-as-a-Service(平台即服务)。提供给消费者的服务是把客户采用提供的开发语言和工具开发的或收购的应用程序部署到供应商的云计算基础设施上去。通俗说就是安装了weblogic、tomcat、mysql中间件或数据库产品的虚机/物理机,可以直接供客户进行软件部署或者开发/运行环境搭建等。

SaaS: Software-as-a-Service(软件即服务)。提供给客户的服务是运营商运行在云计算基础设施上的应用程序,用户可以在各种设备上通过客户端界面访问,如邮件系统、CRM客户管理等。消费者不需要管理或控制任何云计算基础设施,包括网络、服务器、操作系统、存储等等。

在企业内部IT基础设施云,我们一般的关注点在IAAS和PAAS,为企业业务系统提供快速、弹性、敏捷、高效的基础设施服务。如下表是常见的IAAS及PAAS服务:

序号

服务类型

云服务名称

配置

适用场景

1

IAAS

RedHat Linux 7.5 通用服务

CPU(C):1/2/3/4/…32

内存(G):1/2/3/4…..128

磁盘(G):root 100 data 200

Web/AP

2

IAAS

AIX 7.1 TL04通用服务

CPU(C):1/2/3/4/…32

内存(G):4/5/6/7/8…..128

磁盘(G):root 300 Data自选

DB/AP

3

PAAS

RHEL 7.5+WEBLOGIC11G

同IAAS配置

AP

4

PAAS

AIX 7.1 +Oracle RAC 11G

同IAAS配置

DB

6.3.2高级云服务

除了传统的IAAS、PAAS、SAAS服务,还可以考虑发展更高级的云服务,如云数据库RDS、分布式缓存、函数调用、云应用市场、GPU、物联网、人工智能、机器学习等云服务,甚至可以使用serverless云服务。下面主要介绍一下RDS及物联网、人工智能的云服务。

■ 云数据库RDS

云关系型数据库(RDS)是一种稳定可靠、可弹性伸缩的在线数据库服务,支持MySQL、SQL Server、PostgreSQL、MariaDB等引擎,并且提供了主从热备、容灾、备份、回档、恢复、监控、快速扩缩容、迁移等方面的全套解决方案,无需DBA过多干预就可以快速提供数据库服务。

如下图是一个典型的RDS云数据库的架构:

请输入图片描述

企业上云:选型,策略,架构,实践
■ 物联网

物联网(The Internet of things),是在“互联网概念”的基础上,将其用户端延伸和扩展到任何物品与物品之间,进行信息交换和通信的一种网络概念,是信息科学技术产业的第三次革命。下图是物联网的四层架构,主要分了感知层、传输层、平台层和应用层,其中,感知层是物联网的底层,是物联网应用和发展的基础。利用RFID技术、传感等技术,实现对物理世界的智能感知、识别及控制等。物联网的传输层分为有线传输和无线传输,无线传输可按距离分为短距离传输和长距离传输,主要讲述无线传输。物联网的平台层分为四大平台,分别为连接管理平台(CMP)、设备管理平台(DMP)、应用使能平台(AEP)和业务分析平台(BAP)。平台层用于数据的分析与处理,后应用于各个行业。

请输入图片描述

企业上云:选型,策略,架构,实践
■ 人工智能

人工智能(Artificial Intelligence),英文缩写为AI。它是研究、开发用于模拟、延伸和扩展人的智能的理论、方法、技术及应用系统的一门新的技术科学。

人工智能的云服务可以分为很多种,如智能语音识别与交互、人脸识别、图像识别、自然语言处理、机器学习、数据可视化等。

人工智能的技术可以应用很多很广的场景及业务,不仅限于业务,人工智能技术也应用在了银行IT运维工作中,如数据中心的智能化运维AIOPS,使用海量运维数据,发展智能运维,自动发现问题、分析问题、处理问题,达到系统故障自愈,还可以利用态势感知,对故障进行预测等。

■ Serverless

未来的应用应该是不依赖于底层的虚拟机,而是建立在一些serverless的云服务之上,例如开发一个应用,直接使用云上的负载均衡,调用云上的身份认证,使用云上应用市场的服务,把数据存放在RDS中,然后用云监控进行故障分析,用服务治理进行相关的服务监控及调优,使用devops提升效率…这种云模型的高级使用,彻底抛弃了自行申请操作系统并安装中间件数据库的方式,也是应用上云的架构改变。

serverless架构主要包括BaaS(后端即服务:Backend as a Service)和Faas(函数即服务:Functions as a Service)这两种架构,他们没有一直运行的定制服务存在,不占用服务商的计算资源,同共享单车有些类似,是计算机分时租赁方式,按次按时计价。

Serverless主要的优势是低运营成本、简化设备运维、提高可维护性、更快的开发速度。缺点是目前还少有大型成功案例,无法适应所有的场景。

6.4云管理

请输入图片描述

企业上云:选型,策略,架构,实践
有了资源池、有了云服务,如何将各类资源池有机结合在一起管理,实现快速、敏捷、高效、弹性的提供基础设施服务,需要云管理平台来解决,在云管理平台路线选择上每个企业都是不同的,但是主要由几种方式,做个简要介绍:

■ 开源Openstack。采用开源Openstack,可以利用开源社区的优势,获取知识较快,落地相对也较快,但是需要投入比较熟悉Openstack的人员自己研究、测试、持续跟踪、升级,尤其是在没有外部专家人力的情况下,升级、迭代会比较困难。

■ 自主研发。自主研发云平台最大的好处是贴近需求,可以把企业所有的资产管理、IT流程、自动化、配置管理等所有集成在一套平台上,提供端到端、场景化的IT基础设施服务,难点是投入大、开发周期长,而且必须要持续开发。

■ 商业产品。采购一款商业产品(可以是厂商闭源厂品或者OpenStack商业化产品),这种方式见效最快,但是不一定完全贴近需求,往往需要二次开发。

6.5云安全

企业上云后,系统的安全性会集中暴露出来,不管是网络安全,还是数据安全的维度,还是监管安全、企业风险安全的维度,同时云的技术特点决定了云上的安全与传统安全的区别。

考虑云计算安全,首先要满足企业所在行业对信息技术安全的要求,如监管部门对金融业的要求,必须满足信息安全技术网络安全等级保护中第3级(即等保3级),部分核心系统甚至要满足等保4级的要求。

下面是云安全所需要考虑的简单的云计算安全框架,可以从几个方面来考虑云安全:

请输入图片描述

企业上云:选型,策略,架构,实践
这个框架主要包括以下几个方面:

6.5.1基础设施硬件安全

基础设施硬件安全主要包括:

■ 机房安全:

顾名思义,机房安全主要考虑承载云计算的IDC机房的安全管理,涵盖region、az地点的选择、园区/机房的风火水电安全等,如机房供电要来自多个供电公司的独立变电所,防止数据中心全局性的单路供电全安全,为防止极端情况突然停电,还要有UPS短期不间断为设备供电,以及柴油发电机,应对长时间断电场景等。

■ 网络安全:

网络安全主要考虑网络服务要来自多个运营商、多条线路,防止网络中断等;外部、内部所有的网络连接、网络接入都要有多线路冗余,能够在单链路中断服务网络服务不间断等。

■ 设备安全’

关键功能的设备应采用高可用配置或采用其它技术手段使该功能不存在单点故障,设备应支持设备运行状态和资源的监控功能并支持在发生异常情况时发出告警;关键业务集群主机应跨机柜、跨机房或跨数据中心高可用部署等。

6.5.2云计算软件安全

云计算软件安全主要包括虚拟化软件、云管理平台、IT服务管理等软件的安全,也包括各类资源池的安全,如计算资源池、存储资源池、网络资源池等。

■ 基础软件安全

基础软件应从多个方面保证安全,如应确保接口之间进程调用通过认证;应具备内核补丁检测、加固及防止内核提权的能力;应保证用户接入云管理平台通信的保密性和完整性,应具备对基础软件漏洞及时发现并修复的能力等。

■ 计算资源池安全

计算资源池安全主要包括虚拟化软件的安全(如版本的选择,补丁、漏洞的修补等),资源池的管理上要有身份鉴别、安全控制、安全审计、入侵防范、恶意代码防范、镜像和快照的保护等。

■ 存储资源池安全

存储资源池同样包括存储软件的安全,以及管理上的安全等,如多层级访问级别控制和跨物理集群账号权限管理,要有数据的异地备份和备份数据一致性的能力,多租户间数据隔离的能力,多副本、加密、安全传输、故障自动恢复、数据快速恢复等能力。

■ 网络资源池安全

网络资源池安全主要考虑网络架构安全以及访问控制、安全审计、恶意防范、恶意代码防范等安全内容,如虚拟网络全冗余设计,保证无单点、提供应用负载进行弹性扩容的能力,在流量波动情况下也不中断对外服务,VPC隔离能力、网络流量监控、隔离能力等,

6.5.3服务层安全

主要包括IAAS服务、PAAS服务、SAAS服务的安全,其中重点的包括一些所选用软件的安全管理、数据安全、应用安全等,这里主要讲讲数据安全及应用安全方面。

■ 数据安全

数据是企业信息科技的核心资产,核心数据一旦丢失、泄露、被篡改、被删除将会对企业造成很大的损失,其安全性非常高。数据安全主要考虑数据在产生、传输、存储、访问、迁移、销毁、备份和恢复这些环节的安全性,如数据要分类标记、存储、保护,传输过程要加密、防范被破坏等,数据出生产区域要脱敏,控制数据访问权限,数据要定时备份、异地存储、验证恢复等。

■ 应用安全

应用安全主要考虑管理软件及业务SAAS软件的安全性,要有代码后门审查的能力以及对代码打包和发布进行管控的能力,要能够防范篡改、代码注入、DoS/DDoS攻击等,要有完善的交易日志、错误日志等,具备、黑白名单访问、应用访问异常情况进行监控识别的能力等。

6.5.4安全管理

安全的管理是一个比较大的课题,从宏观方面主要包括安全策略和制度、机构和人员安全管理、安全系统、安全运维等。

在云计算中,安全也可以作为服务存在,安全即服务,将一些安全制度、安全策略通过建模、抽闲、归纳最终可以形成一些安全的应用系统和安全的组件,提供直接的安全场景服务或者供其他系统调用实现安全管理。

如某银行在私有云建设过程中,基础设施安全服务层实现了终端安全、系统安全、网络安全、云安全等多个安全服务,应用安全服务层实现了用户认证、客户认证、密码服务、数据安全、安全监控等多个安全服务,形成企业级一体化的策略管理,对整个框架进行管理,各层服务进行管控,落实安全策略、安全管控要求,最终实现企业级、统一的、涵盖多维度的安全管理。

7上云实践步骤

7.1组织架构

企业上云工程比较复杂、繁琐,可能需要从企业的价值链分析、建模,到业务流程的重构,再到应用系统的适配云化开发,再到基础设施的云计算环境构建,一环扣一环,需要上层领导重视、中层主导、下层实施,建立一体化的推进组织,才能更好的完成云化建设。

7.2云化策略

根据不同的系统实际情况,实施不同的策略:

业务重构、系统新建。业务流程完全重构,开发新的业务系统,采用新的技术上云。

业务不变、应用改造。业务流程不变,应用部分做改造,适应云化基础设施后上云。

业务不变、包装上云。业务流程不变,应用基本不变,基础软件升级或替换后上云。

业务不变、系统不变。暂不上云,待系统被代替自然消亡。

7.3推进计划

项目管理办公室(PMO)制定整体计划,并负责推进执行,并协调各方资源、职能处室、厂商等共同根据计划推进。

7.4部署实施

基础设施根据云计算整体规划、资源池方案、实施工艺、系统资源需求清单等,构建云计算资源池、供给资源,提供应用系统上线基础环境。

7.5数据迁移

根据老系统需求,做数据清洗、转换、迁移进入新系统环境,可以使用数据库迁移(如ADG、mysql主从同步等)方案、存储同步方案(NAS、SAN等)、工具迁移方案进行数据迁移工作。

7.6应用上线

最终,应用系统完成上线前的部署、技术测试、业务绿灯测试,将业务切换至新系统运行,可能涉及到多系统联合上线,并做好上线失败后的回退方案。

■ 上线保障

上线过程中,需要提供人员、车辆、通讯、工位、办公场地、食宿等后勤保障工作

■ 网络切换

包括网络访问关系开通、DNS切换等网络切换工作

■ 平台切换

包括操作系统、数据库的启动、运行正常,保证搬迁环境的系统部署一切正常

■ 应用切换

包括外部关联应用系统的切换(如指向原对外服务IP要改为指向新对外服务IP)、本应用的切换(停止原系统应用、启动新应用,新应用对外服务)等等

■ 业务验证

做完应用切换后,需要技术人员及业务人员做好业务验证工作,保证业务切换成功

/* * @Author: your name * @Date: 2016-09-06 00:00:00 * @LastEditTime: 2020-03-17 18:29:35 * @LastEditors: Please set LastEditors * @Description: In User Settings Edit * @FilePath: \htdocs\usr\themes\default\footer.php */