分类 工作 下的文章

微信开发之分清公众平台和开放平台、公众号全局凭证和网页授权凭证

虽然公司自己的网站和给客户开发的项目中都涉及到了微信开发,自己也写了关于微信开发的两篇文章,但感觉自己对微信开发中的一些概念还是容易混淆,今天浏览了下微信公众平台、微信开放平台的后台和相关文档,算是弄清楚了下面这些东西,至于其他还没弄清楚的,以后想到了再说。

1,微信公众平台(https://mp.weixin.qq.com)和微信开放平台(https://open.weixin.qq.com

“微信公众平台是运营者通过公众号为微信用户提供资讯和服务的平台”,登录公众平台账号后,可以看到它有一个不错的交互界面。可以提供给公司的运营人员使用,用来发布消息和提供服务。

微信公众平台的技术文档地址为:https://mp.weixin.qq.com/wiki,接口域名为:

通用域名(api.weixin.qq.com),使用该域名将访问官方指定就近的接入点;

上海域名(sh.api.weixin.qq.com),使用该域名将访问上海的接入点;

深圳域名(sz.api.weixin.qq.com),使用该域名将访问深圳的接入点;

香港域名(hk.api.weixin.qq.com),使用该域名将访问香港的接入点。

文档对接口的说明:“开发者可以根据自己的服务器部署情况,选择最佳的接入点(延时更低,稳定性更高)。除此之外,可以将其他接入点用作容灾用途,当网络链路发生故障时,可以考虑选择备用接入点来接入。”

参照技术文档中的“入门指引”和各个章节,使用相应的接口也可以自己开发程序实现向微信发布消息等业务功能。

微信开放平台:是为开发者(程序员)提供的一个平台,在这里你可以将你的公众平台下的公众号(订阅号、服务号)绑定到你的开放平台账号下,从而可以基于订阅号、服务号做更多的开发。公众号中的订阅号接口权限是有限的,比如它无法获得网页授权的权限,也就无法通过网页授权获取用户的基本信息(比如openID、unionID等)。

另外,更多的开发场景可能是这样:公司A拥有1个订阅号用来发送资讯,1个服务号用来为用户提供一些服务(比如查询资料等),还有1个pc端的网站。那么当用户使用这些订阅号、服务号和网站时,公司A的开发人员如何识别用户身份(确认用户身份的唯一性)。微信公众平台的技术文档“开始开发”--“接入指南”已经对此进行了说明:

“由于开发者经常有需在多个平台(移动应用、网站、公众帐号)之间共通用户帐号,统一帐号体系的需求,微信开放平台(open.weixin.qq.com)提供了UnionID机制。开发者可通过OpenID来获取用户基本信息,而如果开发者拥有多个应用(移动应用、网站应用和公众帐号,公众帐号只有在被绑定到微信开放平台帐号下后,才会获取UnionID),可通过获取用户基本信息中的UnionID来区分用户的唯一性,因为只要是同一个微信开放平台帐号下的移动应用、网站应用和公众帐号,用户的UnionID是唯一的。换句话说,同一用户,对同一个微信开放平台帐号下的不同应用,UnionID是相同的。详情请在微信开放平台的资源中心-移动应用开发-微信登录-授权关系接口调用指引-获取用户个人信息(UnionID机制)中查看。”

2,公众号全局凭证(全局唯一调用凭证)access_token和网页开发中的网页授权access_token

两者不是一个东西,但在调用接口时很容易混淆。简单来说,网页授权token只在微信授权网页登录时会用到,其他业务一般不会用到,而公众号全局凭证的应用范围则比较广。

公众号的全局凭证access_token获取方法:使用公众号的AppID和AppSecret调用获取access_token的接口,AppID和AppSecret可以在可在微信公众平台官网-开发页中获得,接口调用地址和请求方式如下:

https://api.weixin.qq.com/cgi-bin/token?grant_type=client_credential&appid=APPID&secret=APPSECRET

参数说明:

1 参数说明
2 
3 参数           是否必须     说明
4 grant_type      是       获取access_token填写client_credential
5 appid           是       第三方用户(公众号)唯一凭证
6 secret          是       第三方用户(公众号)唯一凭证密钥,即appsecret

返回数据说明:

1 正常情况下,微信会返回下述JSON数据包给公众号:
2 {"access_token":"ACCESS_TOKEN","expires_in":7200}
3 
4 参数    说明
5 access_token    获取到的凭证
6 expires_in    凭证有效时间,单位:秒
7 
8 错误时微信会返回错误码等信息,JSON数据包示例如下(该示例为AppID无效错误):
9 {"errcode":40013,"errmsg":"invalid appid"}

网页开发主要实现的一个业务逻辑就是为用户提供微信扫码登录网站功能(或用户使用手机在微信浏览器中打开网站登录),那么这里就涉及到了微信授权给第三方(网页开发者)获取用户基本信息的问题。

网页授权access_token获得方法:先让用户同意授权获取code,然后通过code换取网页授权access_token,具体可参考:微信公众平台技术文档--网页开发--微信网页授权一节或我之前写的这篇文章:网站实现微信登录之回调函数中登录逻辑的处理--基于yii2开发的描述,获取access_token后才能够继续调用其他接口进行其他操作。

一个可供创业公司借鉴的API架构演进思路

付钱拉是一家做金融云服务的公司,目前对外提供有支付、资金管理、大数据征信、余额增值、理财超市等与金融相关的服务。付钱拉提供的这些金融服务非常简单好用,跟互联网上的大家看到的OAuth,评论等互联网接口类似,对接付钱拉的支付只需要7行代码。金融简单化,互联网化是我们企业的夙愿。但金融服务跟其他服务相比也有几个特点:

  • 安全,稳定压到一切
  • 数据要求强一致
  • 重试成本高
  • 调用链长,延时高
  • 全程可回溯
  • 用户操作谨慎

业务场景的这些特点会随着版本演进,逐渐渗透到付钱拉的整体架构设计里面,后面会慢慢展开。

目前付钱拉仍是一个创业公司,从2014年至今付钱拉经历了4次大的技术架构调整。目前仍在中小规模下运作,如果读者您目前的团队跟我们差不多,那我想会有更多共鸣。所以本文有几个适用范围:

处在技术债的积累期。

开发团队几十人。

硬件规模不过百。

服务调用千万级。

起步V1.0阶段

请输入图片描述

all in one 模式,所有服务都在一起,部署准双机,之所以叫准双机,是因为还略有不同。右边那个webapp里面还有定时任务,上面是网络分发层,下面是DB。是不是很熟悉的感觉?开发框架是Spring+MyBatis。网站前台,管理后台,定时任务,API接口都在一个war里面。所有操作直接打到数据库上,业务和通讯耦合和在一起, 批处理和实时接口也耦合和在一起。

大家看这个很low吧。业务刚起步的时候,逻辑简单,访问量也不高,其实还好。随着公司业务的迅猛发展,几个月后这套架构的不足就体现出来了。比如:

各种模块耦合严重,不能局部扩容。

直接打数据库,IO和CPU都过载。

历史数据沉淀拖慢数据库性能。

发展V2.0阶段

请输入图片描述

解决V1.0的问题,最简单的方式就是拆应用,加机器,加内存,换SSD。把前台、后台、定时、接口拆成4个应用,独立部署。为了解决数据库性能问题,增加多级缓存。JVM里面的localCache,分布式Redis的上线,大大降低了数据库IO。如果业务稳定了,其实这个架构我们会一直沿用下去。

付钱拉遇到的真实情况是随着业务的迅猛发展,平台的功能模块开始了爆炸式增长。各种需求层出不穷,人手也比较紧张,本着先发展后治理的思路。经过3个月的努力,终于把项目写成了一个大泥球,运行速度越来越慢,新增修改需求也越来越慢,Bug越来越不容易捉,最主要性能也扛不住了。这个时候,不改也不行了。

请输入图片描述
思考
泥球一定不好吗?如何拆解大泥球?新业务线如何避免写成大泥球?我们总结了一下,有以下几点:

增强业务的理解和抽象

增强团队协作和知识储备

学会挑重点,合理安排优先级
请输入图片描述

其实如果业务逻辑不是特别复杂,系统对于性能、稳定性要求不是特别高。这套简单实用的架构挺适用于小公司的快速发展的。回头有机会我们把V2.0的架构开源出来,让大家评判一下。

V1.0和V2.0 架构其实没有大多变化,主旋律是拆分解耦和加机器加缓存。这也是目前业界普遍采用的做法。那有没有更好的设计理念?

可以灵活的提高性能;

可以简单的做单元测试;

可以无缝升级新版本;

可以稳步提高开发效率;
请输入图片描述

我们先看两个非常简单的问题:
请输入图片描述

假设付钱拉只提供两个API,一个是做加法,客户端给参数a和b,服务端返回a+b。一个是做++1,客户端get,服务端获取最新值+1后返回。

1+1 是一种CPU密集型操作,API主要做计算操作,而且不需要保存状态,这种服务我们叫无状态化的计算型服务。因为没有状态,无线程安全问题,完全可以并发操作。如果顶不住了可以随时加机器解决。

而++1这种呢,需要获取当前的最新值,才可以做+1操作,是一种有状态的服务。这种服务我们叫有状态的IO密集型服务。

++1 还有一个特殊情况,服务线程还需要考虑并发的问题。再考虑上分布式环境下,状态不能单机保存,还需要考虑集中存储的问题。

以上两个例子,是目前付钱拉API的两个典型的场景。

借这个场景来说明有状态无状态,IO密集,计算密集等API设计时的通用问题。那么怎么解决呢?

我们先从程序的结构上说起,API也是一个程序,按照各位大佬书上说的:程序=数据结构+算法。

算法就是1+1的问题,加法就是一个最简单的算法。++1 更多的是一个数据结构的问题,比如使用Redis的Incrby来做累加,因为Redis的单线程模型,分布式存储和线程同步的问题一并解决了。所以比较好的设计思路是把算法和数据结构完全分离。

如果程序不能完全隔离状态,那就把状态(数据结构)托管到专门的状态存储中间件。比如Redis、MySQL等,逻辑和状态从设计和部署上解耦,即所有的服务都是『无状态化的服务』。
请输入图片描述

基于金融服务要求完全可回溯,再考虑到数据库的并发锁性能问题。更新操作可以理解为先删除再增加,更新操作首先是一个随机IO,定位数据行需要时间。
请输入图片描述
请输入图片描述

另外操作也比较复杂,先删后加,更新还会丢失历史版本,比如更新1->2->3,我们只能看到最终结果3,看不到过程1和2了,所以建议用新增替代更新。

所以 把状态理解成版本,版本只能新增累加,如 git svn 等版本控制工具。

新增操作是顺序IO,一直在表的末尾追加,性能优于更新而且新增不会有并发的问题,更新要考虑并发。另外新增可以保存所有的历史版本,例如新增1,2,3,都在表里面。

思考了这么多…..那么新的架构要满足那些条件呢?

服务化V3.0

综上所述,新版的架构应该具备目前比较流行的”微服务”的特质:

模块化

服务化

异步化

简单可调试

全流程跟踪

原生云支持,弹性部署

3.0这个版本 从webapp切换成了微服务架构:
请输入图片描述

给大家看看我们的事件处理机制:
请输入图片描述

V3.0是一个基于MQ消息的异步驱动的流程组织引擎,整体的业务流程都是消息驱动,上游处理完毕后,把消息扔给下游就不管了。哪个模块出了异常都可以随时终止流程返回给调用方,如果程序正常执行完毕,最末端的模块负责给调用方响应。

那模块如何响应调用方?调用方在发消息的时候,在报文里面放一个UUID的队列名称。调用方发出消息后,就开始阻塞监听这个UUID的返回队列,各个处理模块都可以给这个UUID队列放消息,调用方收到消息后流程就结束了。我们内部叫”用两个异步的消息,完成一次同步的通讯”。

V3.0 上线后极大的提高了我们的处理性能,弹性局部扩容,异步化等特性也都具备了,终于可以喘一口气了。

差点忘了说了,V3.0重构时我们顺便解决了数据的分库分表问题。

数据库集群分了三个大区:

“在线库”主要做实时交易用,日表操作,只保留最新的7天数据。

“离线库”主要做查重和实时交易统计,数据秒级同步,周表操作,保存半年。

“历史库”主要做BI和数据分析,月表操作,永久保存。

V3.0 稳定了半年多吧,也发现了一些问题,也在逐步的完善。有一些基础的设计理念,针对日益复杂的需求变更,还是有点慢。目前我们的核心业务有一部分还跑在3.0这个架构上。其他大部分业务我们都在V4.0这个框架上了。V3.0和V4.0其实是有不同的适用场景的,不是一个完全的新版本替代关系。
请输入图片描述

服务化V4.0

V4.0 相对于 V3.0来说,有几个显著的改变:
请输入图片描述

大家可以对比一些 V3.0的架构图。
请输入图片描述

增加了控制器队列,主要负责消息的编排,各个具体功能模块执行完毕后。

不需要决定把消息给那个下游模块了,而是直接返回给控制器模块,控制器来决定下一个模块是谁。

控制器模块其实也是一个普通队列可以多点部署防止单点故障。

控制器模块的编排是根据配置文件来做的.配置文件里面定义了一个业务的调用链。

配置文件支持简单的顺序,选择,循环和tryCatch等分支流程。

下面是一个例子:
请输入图片描述

单看性能参数,3.0的性能大概是4.0 的2.5倍左右,4.0主要用在业务逻辑多变,性能要求不是特别高的场景下。

下面说一下付钱拉的批处理和调度:
请输入图片描述

我们仿照Hadoop搞了一套调度与批处理,用nas mount网络存储 来替代HDFS实现分布式文件存储。用数据库MySQL来存放调度等meta数据,替代jobtracker。大体一个拉模型,各个任务节点都要主动去MySQL里面轮询任务。

有没有我的任务?

不停的去MySQL里面查…

业务和运维人员可以用sql和我们的工具界面。

操作数据库的记录实现任务的分配 执行 结果反馈.. 重提 .. 可以自动跑批,也可以人工干预。成本不高 但是很简单实用。

这个批处理架构有兴趣的,我们可以单聊,今天就说个架子,不详细展开了。
请输入图片描述

上面这个PPT说的是数据库的一些设计的基本原则。时间关系也不展开讲了。

原文地址 原文链接

VPS 主机国内外控制面板

国外:

VestaCP:http://vestacp.com/(比较推荐的面板,自带中文)
Kloxo-MR:https://github.com/mustafaramadhan/kloxo/(7.0真的很强大,很好看,很实用,有中文包)
Webmin/Virtualmin:http://www.webmin.com/virtualmin.html(很稳定,很安全,自带中文)
Ispconfig:https://github.com/dclardy64/ISPConfig-3-Debian-Installer(官网没看懂这是一键包,有中文包)

i-MSCP:http://i-mscp.net/(简单易用,自带中文)
EasySCP:http://www.easyscp.net/(和i-MSCP一样来自Ispconfig,自带中文)
Ajenti:http://ajenti.org/(轻量级,类似Webmin,自带中文)
zPanel(sentora):http://www.zpanelcp.com/http://www.sentora.org/(支持win,有中文包)

centoswebpanel:http://centos-webpanel.com/(据说比较有发展前途)
Froxlor:http://www.froxlor.org/(很轻量的,适应各种环境)
AlternC:https://alternc.org/(简单)
EasyHostingControlPanel:http://ehcp.net/(还不错的面板,有第三方汉化包)

国内:

http://amh.sh/(4.2版免费)
http://www.wdlinux.cn/bbs/(简单易用,近来爆出严重安全漏洞)
http://www.zijidelu.org/(支持freeBSD)
http://www.kanglesoft.com/(很好很强大)

一键包:

国外:

http://centminmod.com/(据说很适合wordpress)
https://vpssim.com/(很强大的一键包)
http://tuxlite.com/(适用于Debian系列)

https://github.com/Xeoncross/lowendscript(lowendscript演变来的)
https://github.com/alexandreteles/monkeyServer(MonkeyWebServer轻量级的web服务器)

国内:

http://lnmp.org/(用的人很多,适应性很强)
http://teddysun.com/lamp(很好用的LAMP一键包)http://teddysun.com/lamp-yum(适合小内存≥64M)
http://bbs.aliyun.com/read/151729.html(阿里云论坛看到的)
http://blog.linuxeye.com/31.html(多种配置,软件较新)
http://lnmpp.net/(支持postgresql,支持ARM)

http://www.hhvmc.com/thread-17-1-1.html(有hhvm的一键包)
http://shuang.ca/llnmp/http://llsmp.cn/(有LiteSpeed的一键包)
https://www.lxconfig.com/thread-69-1-1.html(有openresty的一键包)
http://blog.7qy.com/html/1575.html(有cherokee的一键包)
http://lamp.phpstudy.net/(有Lighttpd的一键包)

/* * @Author: your name * @Date: 2016-09-06 00:00:00 * @LastEditTime: 2020-03-17 18:29:35 * @LastEditors: Please set LastEditors * @Description: In User Settings Edit * @FilePath: \htdocs\usr\themes\default\footer.php */