手机建网站优帮云,公众号制作平台,高校网站建设存在问题,电子制作diy在上一篇中#xff0c;我们详细分析了微信订阅号和服务号的区别#xff0c;在本篇中#xff0c;将进入正题#xff1a;升讯威微信营销系统的功能设计及架构设计。 一、功能设计 1#xff09;设计目标 ◇ 为微信服务号提供运营及管理所需的各种功能#xff0c;包括微官网、… 在上一篇中我们详细分析了微信订阅号和服务号的区别在本篇中将进入正题升讯威微信营销系统的功能设计及架构设计。 一、功能设计 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与它们进行通信对于中控服务器和定时任务服务器存在需要外网交互的部分我们通过一个代理服务器来实现。 3技术选型 对于这样的项目无论是商业平台还是开源平台都是可以的都不会有太多障碍。 本项目基于微软平台开发并使用了一些基于Linux平台的开源应用作为辅助。 这里要指出一个关于跨平台的问题有些开发人员认为微软平台不能够跨平台是一个问题关于这一点我认为“跨平台”本身是一个伪命题和伪需求我从没见过正经项目在运维过程中迁移技术平台的案例一定是在设计时就确认了部署平台。微软平台的优点是技术方案成熟可靠性较高开发效率高缺点是运维时的软硬件成本较高。开源平台的优点相反运维期间的软硬件成本要低几个数量级但是前期的综合开发成本较高可靠性更多的依赖于人的因素。 后台 1ASP.NET MVC5 Razor 2Web API 3S-ORM 4Microsoft Enterprise Library 5其它组件在相关章节介绍 ASP.NET MVC 没有悬念视图部分使用 Razor生产性和可维护性都极高。如果发现项目中存在非常高频请求的页面可以对特定页面实行完全静态化的HTML代码和前端异步请求的方案处理。这样的情况可能出现的场景在手机端但是没有必要整个项目都使用这种方式处理。 此外关于数据访问层没有使用 Entity Framework有几个方面的考虑a.开发运维时更新数据库表结构等比较麻烦b.性能问题关于执行效率我们可以通过许多开发技巧进行提升但是对于团队开发来说这个隐性成本太高了c.灵活性问题在许多较复杂的应用场景中数据库表结构和实体对象的映射关系不一定是简单的一对一隐射可能存在分解、组合、包含等多种情况。所以在ORM层面使用了我的另外一个开源项目S-ORM严格来说它不是一个ORM而是一个轻量级的内存数据映射模块详细的介绍请移步http://www.cnblogs.com/sheng_chao/p/4553832.html。 项目的日志处理统一异常处理使用了微软企业库Microsoft Enterprise Library。 前端 1jQuery 2其它组件在相关章节介绍 对于前端实现要尽可能多的兼容更多的浏览器包括现代的古代的力所能及的都尽可能兼容。此外前端分为两个部分PC端和手机端在具体实现上略有不同。 在前端技术选型中考虑过AngularJS、Knockoutjs、Backbone等框架毫无疑问都是牛的框架但是在这个项目中我都没有使用最主要的原因是出于生产性的考虑我认为使用这些框架的生产性不够高或许在单页面应用Single Page Application场景中它们更能大展身手但是对于这个项目来说没有SPA这样的需求相对来说比较传统这种场景下网页前端的每个页面都是独立的区域、与其它的页面完全没有任何依赖、引用的关系这一点对于后台开发或者应用程序开发有很大区别在大多数页面并不那么复杂的单个页面中实现MVC是否有必要能够得到什么回报不要把“学技术”放到考量因素中这不是做项目需要考虑的问题开发人员也不应该带着这种目的做项目这是自私的。 可能有开发人员认为使用优秀的开发框架可以提高代码可读性和代码品质关于这一点我认为代码的品质和可读性与所使用的框架完完全全没有任何关系完全取决于程序员的编码水平和态度。 前端技术不是我的强项关于这一块内容请前端技术的牛人斧正。 缓存 1 Redis 在本项目的开发中缓存的应用经历了从 memcached 到 Redis 的转变转变的具体原因将在后续介绍缓存实现的篇幅中详细介绍。 数据库 1 MS SQL Server 在数据库层面大量使用了存储过程处理业务逻辑并做到99.9%以上的参数化查询,一是可大幅提高数据库请求效率二是防止注入攻击。为什么不是100%在个别场景中有一些特例这些特例可以通过统一的函数进行安全方面的过滤并且这些特例中的输入参数并不依赖于外部提供后文将详细说明。 原文地址http://www.cnblogs.com/sheng_chao/p/5801401.html .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
