GitHub：https://github.com/iccb1013/Sheng.WeixinConstruction
因为个人精力时间有限，不会再对现有代码进行更新维护，不过微信接口比较稳定，经测试至今没有变化，功能依然全部可用，你可以在此基础上，二次开发，完成你的业务功能，也可以抽取本平台中的代码复用在你的项目中，请遵循 MIT 开源协议保留我的版权声明和网站链接即可。

GitHub：https://github.com/iccb1013/Sheng.WeixinConstruction.WeixinContract
微信协议包装的项目还有一个单独的工程，这个工程的版本稍新，我会进行一定的更新维护，如最近增加了几个小程序开发需要使用到的接口。但是注意因为代码结构经过优化调整，直接引用到升讯威微信平台中，需要修改一些类的引用和名称。

升讯威微信营销系统开发实践系列
升讯威微信营销系统开发实践：（1）功能概要与架构设计
升讯威微信营销系统开发实践：（2）中控服务器的详细设计
升讯威微信营销系统开发实践：（3）功能介绍与此项目推广过程的一些体会
升讯威微信营销系统开发实践：（4）源代码结构说明 与 安装部署说明

微信开发系列教程，将以一个实际的微信平台项目为案例，深入浅出的讲解微信开发、应用各环节的实现方案和技术细节。

本系列教程的最终目标是完成一个功能完善并达到高可用性能指标的微信管理软件，所以除了与微信本身紧密相关的对接和应用技术，还会讲到其它相关的所有知识点，从技术选型，架构设计，数据层的设计，API的设计，数据传输协议的设计，再到细节的前端的设计及技术应用，后台开发中的各方面技术，都会涉及。同时，在架构设计中，会考虑到运维领域的诸多问题，会涉及到部署环节中负载均衡及CDN分发，服务器流量及带宽控制等因素。有许多开发人员对运维领域的工作不熟悉造成项目运维阶段成本高，难度大，希望本文能够帮助到你。

在上一篇中，我们详细分析了微信订阅号和服务号的区别，在本篇中，将进入正题：升讯威微信营销系统的功能设计及架构设计。

一、功能设计

1）设计目标

◇ 为微信服务号提供运营及管理所需的各种功能，包括微官网、微会员、活动中心、营销辅助、微信支付。

◇ 提供简洁友好的功能画面，使非专业技术人员也能够轻易的使用。

◇ 提供可独立于系统之外的插件功能或接口，可轻易对接其它系统或功能模块。

2）详细设计

如图，功能的设计从业务上划分，分为五大块：

◇  微官网

         微主页提供若干预置的模版，可以通过上传自定义的主题图片形成自己的微主页，对于有一定开发能力的使用者，提供模版引擎功能，使用一个类似于轻量级CMS的功能，定制自己的微主页。

         电影排片需要写一个蜘蛛程序进行抓取。

◇  微会员

         需要实现一套积分系统，包括在后台对积分规则的设定。积分商城与大多数商城系统类似。

         卡券功能需要支持后台派发和前端在线下通过二维码核销，这一块与微信原生卡券有一个重要区别，在于领取的方式，微信原生卡券主要是自主领取，比如扫码、分享等，但是对于部分线下商户，卡券的派发是要严格管控的，比如电影院的兑换券、景点的门票等，这种场景目前微信自带卡券不能实现。

◇  活动中心

         必须将所有的活动全部模版化，使用户能够简单配置就发起活动，并在活动进行的过程中提供运营数据报表。

◇  微信支付

         除了打通微信支付以外，需要提供线下的充值和消费能力，比如会员直接在线下向服务人员现金充值，或线下购物时刷二维码消费自己预存的现金，这里实际上意味着需要实现一套比较完整的消费系统。

◇  营销辅助

         能够提供各种运营数据，并提供邮件通知、短信通知的能力。

二、架构设计

1）设计目标

◇  稳定可靠，低耦合高内聚，可维护性强。

         稳定可靠主要取决于设计及编码水平，这个无需多解释。低耦合高内聚应该也是大家都了解的原则，为了实现这个目标，项目会按功能模块进行拆分和抽象，具体拆分方式请见下文的详细设计。

◇  易水平扩展，易运维。

         将高频请求的部分和低频请求的部分分解，将内网请求与外网请求分解，可分布式部署，将内网请求部分完全隔离在防火墙之后或内网环境中，并使对外的高频请求的部分可通过增加服务器来增加承载能力。在设计之初就需要考虑负载均衡及CDN分发所带来的问题，在负载均衡方面，我们以负载均衡不开启会话保持为设计指标，此外，我们需要将所有用户上传的文件，或发送的文件，在独立的文件服务器存储，以便于CDN分发和控制流量及带宽，要知道服务器的流量及带宽费用是相当可观的，同时也避免文件传输对服务器带宽的占用而影响业务数据的处理能力。

◇  所选技术应用成熟，生产性（开发维护的效率）高，编码实施难度较低，后续开发容易。

         在具体的技术选型上，选择成熟稳定的技术方案，而不是“牛”的方案，这一点非常重要，因为我们不是在做研究，我们是在做项目。或者从另一个角度来说，你对技术“牛”和“不牛”是怎样理解的。在此项目中我们考量以下几个因素：

         a.是否成熟稳定，后续支持怎样。成熟稳定通常代表着问题较少，团队学习成本低，接纳度高，后续支持指的是是否有商业公司或开源社区积极的维护更新。

         b.生产性怎样，是否可以提供足够高的生产性。生产性指的是开发维护的效率，软件开发过程中最大的成本是人力成本，如何用更少的人做到更多的事，甚至说在市场竞争中你的速度快不快，都相当重要，对于商业项目，我不需要你知道回香豆的“回”有几种写法，我只要你又快又好的给我写一百遍“回”字即可。

         能解决我的问题，成熟稳定，生产性高，可以称之为“牛”的技术。

◇  数据库必须支持分库存储

         基于承载能力扩展性和业务方面的考量，必须要能够将不同的公众号数据存储到不同的数据库服务器上。

2）详细设计

         架构设计我想分为两个部分说明，一是开发架构，二是部署架构。这两个不同角度的设计互相影响或者互相制约，必须在设计期间就把握好大方向，做好这件事情需要设计者除了懂开发，还要懂运维，否则很容易造成前人挖坑后人填坑。

         1.开发架构

         注意图上的一个矩形模块并不一定就代表着一个程序集，一个逻辑上的“模块”可能由多个程序集共同构成。

         从上向下简单分析，首先是管理端的UI层和手机端的UI层，我习惯将之称为Shell。从图上可以看到管理端Shell和手机端Shell是分开的两个模块，在我们的解决方案中它们是两个不同的工程，我也看到过一些微信项目将管理端和手机端放在一个工程中，无论是从安全性、可维护性上说我都强烈不建议你这么做。完全分开的好处有很多，首先是部署成本，管理端一般情况下是不需要应对大量请求的，而手机端有这个需求，在部署时管理端甚至只需一台服务器即可，而手机端则需要更多的服务器和带宽支撑，另外在工程的前期运维阶段，管理端的版本发布频率可能高于手机端，完全隔离的开发和部署可以避免在发布管理端时影响到手机端的业务，第二是安全性的问题，手机端从工程上就是完全不包含任何管理功能的，可以在一定程序上提高安全性。

         接下来是若干辅助服务，报表服务、文件服务，这两个服务是独立的Web工程。和管理端或手机端并不是一一对应的关系，一个报表服务器或文件服务器可以为多台管理端或手机端Shell提供服务。

         报表服务器直接提供报表查询和显示的画面，嵌入在管理端中。

         文件服务器提供文件上传下载功能，这个服务有几个技术细节需要注意，聪明的你或许已经想到第一个问题：跨域上传的问题。管理端和手机端都是独立部署的，所使用的域名自然是不同的，那么在浏览器中上传就存在跨域的问题，不过这个问题并不难解决，我将的后续篇章中介绍，另一个就是对于（嵌入在微信中的）手机端来说，是不能直接上传文件的，必须先把文件发送到微信后台，获取媒体ID，再下载下来，这个过程需要文件服务器完成，最后是关注服务号的会员，发文件到服务号上，实际是发到了微信服务器，我们的文件服务器要能异步的把这些文件从微信后台下载下来。

         定时任务是一个或若干个Windows服务，用于定时执行一些业务。

         业务核心模块这里的介绍比较笼统，在项目中实际对应着实现不同功能的诸多程序集，限于篇幅和本章节的主旨，还是留到后文中详细说明业务核心的设计和实现。

         中控服务器主要的功能是维护调用微信API所需的AccessToken，与微信对接时，根据公众号的AppId和AppSecert，你可以获取到一个有效期为2个小时的AccessToken，调用几乎所有的微信接口都需要这个         AccessToken，当然你不能在每次请求API时都获取一个新的AccessToken，这是完全没有必要的，所以需要一个独立的服务来处理这件事，其它模块需要使用AccessToken时，从中控服务器获取。

         微信SDK并不是微信官方提供的，是项目里需要自己实现的部分，微信官方并没有提供完善的开发包，只有若干示例。网上有一些开源的微信SDK，但是或多或少存在一些问题，此处使用的是我们自己实现的SDK包。

         基础架构部分涉及到数据实体的定义、数据协议的定义等等，数据协议指的是各Web工程之间以前单个Web工程中前后端通信所使用的协议。此外还包括许多共通的功能实现也在这里。

         服务模块封装了项目中所需的许多服务，如：日志、缓存、统一异常处理等等。

         最后是数据层，数据层没有使用Entity Framework，使用的是我的另一个开源项目S-ORM，下文的技术选型部分有简略的说明和介绍。

         2. 部署架构

        如图所示，我们的部署目标是需要支持易于水平扩展的分布式部署。管理端Shell、手机端Shell、报表服务器、文件服务器都必须能够通过增加服务器快速扩充承载能力。

        在上文中提到，我们在开发环节必须以负载均衡不开启会话保持为一项技术指标，这意味着从浏览器中发起的请求每次都可能落在不同的服务器上，我们就不能使用服务器Session存储会话数据，需要在开发阶段就实现一套基于独立缓存的Session机制。

        数据库服务器、缓存集群、中控服务器、定时任务服务器都部署在内网中，其它项目通过内网IP与它们进行通信，对于中控服务器和定时任务服务器，存在需要外网交互的部分，我们通过一个代理服务器来实现。