本文主要从最初的聚石塔容器服务EWS开始讲起，进而分享了EWS
高质量架构产品化的C2B方案和全渠道方案，着重说明了EWS的技术实现，包括EWS的总体架构以及EWS的功能实现等。
直播视频：点此进入
PDF下载：点此进入
以下是精彩内容整理：
聚石塔
聚石塔是阿里的电商云平台，聚石塔主要向商家提供电商云的支撑，能够更方便的和阿里做技术上和系统上的对接，所有的ISV和服务商开发的系统都部署在聚石塔上。今年整个零售平台提供了16字目标：聚焦体验、升级消费、赋能商家、繁荣生态。聚石塔扮演的是技术赋能商家、繁荣生态的角色。
聚石塔容器服务-EWS
EWS分为三个层面。第一环是PaaS的容器云，主要包括一些镜像的管理、机器资源的管理等，这一环是在原有的IaaS云基础上容器化一种容器PaaS云计算，目前Docker云平台服务商都在做这个事情。第二环是把淘宝的高质量互联网架构提供出来，会提供弹性计算、负载均衡等，希望两三个人的团队能够支撑像淘宝一样稳定的系统。第三环提供IT解决方案，比如OMS、互动游戏等。整个三环是商家事业部在电商云提供了一套从技术到产品到解决方案的完整体系，称之为EWS。
EWS 商业化的容器平台
EWS起初叫TAE，TAE1.0做到安全开放的目的；TAE2.0做到全架构服务，比如MySQL互备等，给开发者更方便、更高的体验；EWS从提供发动机到插座到照明的解决方案，是一个商业化的容器平台。
EWS 高质量架构产品化——C2B方案和全渠道方案
C2B定制解决方案
如图中类似的系统是ISV开发的，如何保证ISV开发的系统在淘宝的交易主链路上的稳定性、用户的体验等？
在服务了很多ISV后，我们总结了“老中医模式”，一套方法论，最后输出一套产品，平台方和客户方要求是有差异的。平台方希望高质量架构，标准化，关注运维，强调质量；客户方希望功能第一，多样灵活，关注开发，强调成本。
典型系统的架构演进
一个用户的系统基本上经历了五个步骤。
根据EWS在C2B开放场景下的目标和定位，我们的解决方法是由一个全架构的PaaS平台，将构建、运维、发布全部产品化，然后再把高质量做成固有的服务，包括弹性计算、多Region、负载均衡、健康检查和IP迁移等，把自己的系统建设成高质量架构，和把高质量架构作为一种能力输出完全不一样！若把高质量架构能力产品化输出，需要考虑到更好的扩展性和更好的兼容性。
全渠道
O2O 解决方案
商场同款的商品，下单可以选择门店发货或者门店自提。
门店原有线下的IT系统去帮助做订单的管理、库存的管理、供应链的管理，但线上线下怎么融合，就是摆在全渠道O2O的问题。很多商家是由软件服务商做开发，那么传统软件开发商怎么和互联网做对接，如何做互联网架构，原有系统怎么无缝迁移？我们总结了“老鸨模式”，老鸨模式是经纪人模式，它具备了大型软件的开发能力，进行包装变成互联网模式的软件，传统开发商都有去IOE的需求，软件SaaS化，我们更多的扮演的是咨询的角色，帮助他们向互联网架构迁移。
零售IT 互联网化的驱动是零售商业互联网化。
EWS技术实现
互联网架构八荣八耻
以可配置为荣 ，以硬编码为耻
以可互备为荣 ，以单点为耻
以可无状态为荣 ，以有状态为耻
以可随便重启为荣 ，以不能迁移为耻
以整体交付为荣，以部分交付为耻
以标准化为荣，以特殊化为耻
以自动化运维为荣，以人肉化运维为耻
以无人值守为荣，以人工值班为耻
高质量架构6个维度的20个能力
EWS总架构
系统架构分为左右两个部分，用户访问链路和运维管控链路。用户访问链路是指下单背后的流程逻辑是怎样的，运维管控链路是指一些后台能力。用户访问首先会访问到接入层，经历防安全攻击的扫描后，接下来是一个Tengine的集群，所有的访问日志都会从LogAgent写到日志服务子系统，日志服务子系统是一个消息队列，会不停地收用户日志并做排序、去重等来保证分布式日志的保序，后面会有一个大的Storm集群处理分布式日志，然后Tengine也会访问到容器中，容器中部署自己写的程序，也会有一些应用日志，这就算整个访问链路走过的流程。管控链路中，互联网架构下想做一个好的部署，首先要到达管控中心，通知用户将健康检查关掉，然后通知路由中心将Tengine的节点摘掉，在不服务状态下发布，接着将包传到中间的OSS存储上，再通知分区的管控去拉代码包。
多机房资源池
EWS支持多机房能力。目前支持五个机房，具备多机房的资源管理和系统部署能力。
图中界面为分Region资源池的管理，有以下三点：
- 多机房资源池化：命令方式：curl
https://as-hz.acs.aliyun.com/agent/PmndU | sudo bash；购买有EWS镜像ECS主机。
- 多机房资源 OS化：能够把多机房的CPU，内存，带宽资源调度，像单机操作系统一样统一调度。
- 快速新建机房的能力：用户使用EWS 多机房部署功能，一键新部署到新建Region。
官方Service
EWS后端软件是以Service来执行的最基本单元，EWS官方镜像覆盖80%常用系统软件，提供服务从功能、性能、稳定性和可维护性四个维度来考虑的。
EWS 系统模型
- 一个Region 有多个 Service Group
- 一个Service Group 有多个 Service
- 一个Service 有多个Container
- 一个Container 一定在一个ECS里面，可以独占，也可以和其他Container混部
- 一个Service 可以属于不同的ECS，也可以数据同一个ECS
- POD 是多个Service的逻辑组合，系统编排和调度以POD为单元
Service管理
基于EWS系统模型，核心是对Service管理，Service最重要的是发布功能。其中包括：
- 包发布： 支持大文件程序上传，断点续传。Zip 包，War包，Jar包，Http
- Git发布：每个Service一个独立的Git仓库
- 灰度发布：可以对Service下面的Container分组，对分组进行发布，来实现灰度发布
- 回滚发布：每个Service会保存 10个最近的发布版本，可以回滚到任意一个
- 预发布： 可以将两个Service分为一组，让Service1 作为 Service2的预发环境
EWS统一接入层
除了Service管理，还有接入层。接入层主要提供以下几个功能：
- 域名：为用户每个应用提供一个域名，用户也可以通过cname操作添加新的域名。
- 负载均衡：提供了七层负载均衡服务(HTTP&HTTPS)，包括四层的TCP。
- 安全防护：配合云盾，高防IP，TMD，WAF防御DDOS，CC，SQL注入，XSS，跨站等各种攻击。
- 健康检查：应用级别健康检查，端口网络检查，脚本健康检查。
负载均衡和健康检查
- 每一个Service，下面的所有Container，会Round-Robin 负载均衡
- Service域名、Service下面的Container 都有健康检查
- 域名健康检查主要检查连通性
- Container健康检查 主要检查可用性，也就是对应的ECS是否挂了
- 可以自定义健康检查脚本
EWS弹性计算
系统编排和混布
- 系统构建的编排 ：新建服务
- 发布的编排：按顺序，依赖关系编排
- 混部：核心是资源的池化
弹性扩容和缩容
- 优雅发布，热升级，不停服升级
- 垂直扩缩容，水平扩缩容
- 手动扩缩容、自动扩容和缩容规则引擎
健康检查和迁移
- 健康检查：机器故障检查，应用故障检查
- 迁移：有状态迁移、无状态迁移，IP地址漂移、域名漂移
- 检测和恢复规则引擎
EWS在后台都已经实现了，但是在前台还没有完全开放。一些场景中用户并不知道究竟该迁移、摘掉、告警还是重启，如果用户有这方面的需求，可以找到对应的小二，会在后台帮用户把规则配置上。
动态迁移
- 扩容镜像预热，保证迁移时传输最少量的数据
- 无状态迁移扩容，不停服， 分钟级
- 有状态配置类迁移扩容，不停服，分钟级
- 混布 java1：2 、php1：4
- 故障告警检测分钟级
- 有状态数据类迁移扩容，利用Docker镜像概念，分钟级
EWS 监控和APM
系统健康靠监控，我们提供了应用监控，服务端监控以及客户端监控等。APM是应用性能管理，包括内部Redis调用、MySQL调用是不是够好，在程序中是不是有瓶颈，都会可视化的表达出来。
EWS总结
EWS提供了镜像服务，网络层防攻击，计算层将ECS资源池化，具备多Region的能力，还会和阿里云的存储类动态的服务无缝的打通，走内网高速通道，接着会给用户控制台，可以做可视化操作。