C/S架构入塔改造案例

更新时间：2015/09/18 访问次数：38014

背景
改造方案
改造评估
优化建议

背景

为了提高电商业务处理效率，通常会使用C/S架构来搭建ERP等业务系统。Client/Server (客户机/服务器) 结构，客户端和服务器端的程序不同，用户的程序主要在客户端，服务器端主要提供业务处理与数据管理等，客户端程序完成用户的交互。

聚石塔要求业务逻辑处理放在服务器端完成，标准三层架构符合此规范，即客户端用于业务数据展现与用户交互操作，服务器端处理业务逻辑与存储数据。两层架构需要将客户端的业务处理剥离出来，转移到服务器端。

改造方案

原系统说明

系统平台：Windows Server+IIS+MS Sqlserver

开发语言：.net

服务器：自有服务器，托管到数据中心

系统架构：采用C/S三层架构

客户端为自开发Windows应用程序，用于用户交互，有部分业务逻辑直接访问淘宝API；

应用层采用WebService和WebServer来与客户端交互，并进行业务逻辑处理，所需淘宝订单等数据通过淘宝API获得；

数据层存放订单信息、商家业务信息、账号及管理信息，同时将部分业务逻辑通过存储过程放在数据库中进行处理。

架构图如下：

新系统改造说明

系统平台：Windows Server+IIS+MySQL

开发语言：.net

服务器：VM+RDS

系统架构：采用C/S三层架构

客户端为自开发Windows应用程序，用于用户交互，将访问淘宝API的业务改到服务器业务逻辑层；

应用层采用WebService和WebServer来与客户端交互，并进行业务逻辑处理，将API取订单与商品信息模式改为从RDS推送库中读取，状态回传及其他业务数据通过淘宝API操作获得；

数据层改为MySQL，使用RDS存放商家业务信息、账号及管理信息，同时将部分业务逻辑改为MySQL存储过程放在数据库中进行处理。

架构图如下：

改造评估

聚石塔架构规则

规则名称	规则要求
系统部署	购买vm和RDS，应用部署在VM上，数据库迁移至RDS上
RDS选型	RDS类型选择mysql
数据库安装	DB部署在RDS中
系统架构	产品是三层架构，业务逻辑在server端运行
API调用	API的调用在塔内VM进行
业务逻辑	1) ERP系统的履单业务在塔内，如订单下载，合\拆单，审单和发货； 2) WMS系统仓储发货退货单、盘点单、调拨单等逻辑及处理的数据回流进塔内； 3) CRM的会员管理逻辑以及订单判断逻辑在塔内运行；
数据存储	1) 增值类接口返回的数据在VM服务端处理之后存放在RDS中； 2) 订单履单业务（下单、合拆单、审单、发货）处理的数据回放在RDS中； 3) R2、W2类数据要求存放在RDS中；（R2\W2数据参考：//open.taobao.com/doc/detail.htm?spm=0.0.0.0.2i9GYM&id=1002）；

性能评估

使用RDS数据推送，订单等数据实时推送到数据库中，应用在VM中通过内网高速读取，不丢单漏单，获取订单无延迟，比塔外通过互联网访问淘宝API获取订单速度快，稳定性高。

VM和RDS支持弹性升级，通过负载均衡可弹性扩充业务订单处理性能。

成本评估

a) VM与RDS的硬件运维保障由聚石塔支持，降低人工运维费用；

b) 提供前端防火墙产品，提高系统防护安全性；

c) 从MS Sqlserver转到MySQL的转换，减少了数据库产品的授权费用；

d) 塔内API调用，极大降低API调用收费费率。

优化建议

此系统采用类SAAS模式，一组VM+RDS为一批客户提供服务，整个平台可以横向扩展。目前的物理架构无法对全部VM和RDS进行资源平均分配，建议按以下方案调整物理架构：

a) 使用SLB来对VM进行全部请求平均分配，通过监控VM的压力来动态增减VM数量或调整规格，VM异常后也可将客户请求迁移到其他VM，保证服务的连续性。因此，VM产品需增加API接口来提供性能监控与自动购买功能，自定义镜像生产VM功能。

b) 通过监控RDS压力来动态增减数量或调整规格，可以考虑将RDS划分为数据推送组、业务组、权限及管理组进行分别监控管理。RDS产品需增加API接口来提供性能监控与自动购买功能。

聚石塔后期会提供相应的产品监控、购买、升级、操作接口，来实现监控到资源调整的自动操作，实现系统完整的SAAS化。同时为客户提供更细的规格订购与更短的弹性升降级方案，保证资源的合理利用，成本计算更佳方便，使ISV可以为卖家提供按订单量等多样化的计费方式。

FAQ

关于此文档暂时还没有FAQ

有用(0) 我要提问

开放平台

聚石塔