概述

SaaS (软件即服务)是一种许可和交付模式,其中软件由提供商集中托管和管理,并通过订阅的方式提供给用户,用户也可以按需或者即用即付方式进行购买。所有基础结构、中间件、应用软件和应用数据都位于服务提供商的数据中心内。提供商负责管理硬件和软件,并根据适当的服务协议确保应用和数据的可用性和安全性。现在很多传统软件向SaaS“转变”时,更多的是向平台化SaaS软件靠拢,借助此模式来交付的产品优势很多,比如:

  • 提供灵活的方式满足客户需求
  • 提高运营效率,使其专注于产品
  • 打破地域的限制,全球覆盖面,从任何位置访问应用数据
  • 按需交付,多维度
  • 自传播
  • 隔离性、安全性、可定制性度高

平台+软件=平台化SaaS=支撑层+应用层

SaaS平台的挑战

我个人觉得传统软件向SaaS过渡原因主要分为两方面:

1.从外因分析是市场趋势、价值和效率的方式转变

传统软件在其整个生命周期内,价值的体现最终要依赖于大客户需求+解决方案+(服务能力)+销售(话有点大,呵呵)。而在其生命周期过程中,无论是任何一方都在变化,市场、需求和趋势也在发生变化,等产品面向市场时,其实已经"慢半拍或者多拍"了,很多决策主要依赖于"拍脑袋",粗略的数据分析和统计很难满足复杂多变的外因。

2.从内因分析无非是弄清楚以下关键的内容

  • 什么对客户有价值
  • 怎么快速交付价值
  • 产品的核心价值、杀手锏是什么
  • 怎么知道做的对不对

最终我们产品的目的:要发现和快速交付价值,所以最后的本质是效率和价值的优势,而转型的问题又变成了组织的问题。

进而在发生质变的过程中需要不断的完成量变的挑战,那么会有如下挑战去突破:

1.如何重新设计组织的能力

重新设计组织的能力

2.如何去除不务实的需求,进而统一需求列表并打通用户反馈渠道**

需求问题:

  • 如何对需求划分,需求场景?
  • 如何以业务为单元,如何评估,怎么梳理业务逻辑,评估系统规模,展开系统设计?
  • 如何建立有效的沟通机制及时与用户进行沟通,确定好需求?

用户反馈问题:

  • 如何打通售前和售后的用户反馈?
  • 如何打通产品阶段的用户反馈?
  • 如何打通运营阶段的用户反馈?

3.如何搭建SaaS基础的技术、架构(技术架构、业务架构、数据架构)、运营平台

纯技术硬核+数据支撑+应用+运营融合体的"大杂烩"

4.如何选择SaaS软件服务

  • 软件有没有能够帮助客户提高运营的水平,获得从未有过的新知,从而帮助客户企业的员工建立一种新的能力,是软件成熟度和客户口碑的关键,产品最好能透射专业和行业最佳实践?
  • 在线API、文档、在线服务,需求为租户提供健全的用户入场协助?

SaaS挑战核心是平衡,需要面对很多矛盾点,有效决策和逻辑性的思考,建立快速试错和纠正的机制,寻找出一系列的平衡规则。【收入、成本和增长】

基于Docker微服务式构建SaaS解决方案

容器技术加速应用云化,现在很多云厂商基于微服务的架构设计模式来实现SaaS,而服务的载体依赖于Docker实现,主要是Docker具备很多天然优势能很好的满足SaaS。即通过封装、隔离、高效来解决私有化部署、安全问题、大客户问题、定制化问题。很多机遇SaaS化比较典型的技术架构网上很多,感兴趣的可以参考下。废话不少说,让我们开启Docker的实践之路吧,由于微服务架构模式涉及的东西很多,给华为微服务框架打个小广告,已经纳入Apache了。如下图所示:

micro-service

本篇博客只介绍Docker Service的Stack应用部署和管理,后续的博客再详细介绍,微服务架构模式和Docker内核技术,如下图所示。

Docker

计算机经典的一种解耦思想:分层,并不像kvm(基于内核的虚拟机),配合QEMU(处理器虚拟软件),需要CPU支持虚拟化技术(并且在BIOS里打开虚拟化选项),效率可达到物理机的80%以上,kvm在实现虚拟化过程中需要配合其它的类库:QEMU、libvirt等,但是在网络虚拟化(SDN)和存储满足跨AZ和调度是十分复杂的。当然Docker也有不足,特别是在安全性和Kernel依赖方面,现在正在按照OCI进行模块化。

Docker Stack应用的部署和管理

我们来看下Docker Stack体系结构:

Docker Stack

我们采用一个Demo来实践Stack,该Demo来自Docker大牛Nigel的官网,如下图所示,该应用由 5 个服务、3 个网络、4 个密钥以及 3 组端口映射构成。

Docker Apps

我们首先编写Stack文件,需要创建over-lay网络、秘钥和服务,包括后续滚动升级的副本、延迟关闭等

其次我们需要部署我们的应用,Docker Stack部署依赖于Swarm模式,所以要合理规划管理和工作节点。下面让我们搭建实验环境:

1.创建Swarm

1
2
#先让管理节点加入工作集群中
docker swarm init

2.添加工作节点

1
2
3
4
#让相应的多个工作节点加入到工作集群中
docker swarm join --token xxxx
#检查确认各个角色节点是否正常
docker node ls

3.添加label

1
docker node update --label-add pcidss=yes worker-1

4.可以通过openssh生成秘钥

1
openssl rsa:4096 xx.key xxxx

5.让docker使用生成的秘钥

1
docker secret create xxx token

6.部署app服务代码

1
docker stack deploy -c stack.yml demo

7.检查相应的服务和node是否正常

1
2
3
docker stack ps demo
#如果相应的服务副本出现问题则可以查看日志
docker service logs

8.管理应用

比如我们想扩充服务的副本数或者部分升级都是可以的

1
docker service scale

可以访问相应的app了,如果业务代码采用了微服务的架构模式,要注意服务的状态性、链路熔断、数据的一致性问题了。