微信小程序如何连接自定义服务器

前言
最近做小程序，一直用的是本地服务器接口，在用真机测试的时候，发现动态数据并不能同步，研究了一下发现 *** 作很简单
2配置步骤
1首先打开微信开发者工具，打开右上角的详情，点击本地设置，勾选下面的不校验合法域名
2打开手机的热点，用电脑连接手机热点（保证在同一网络下）（很重要）
3打开电脑的控制面板----》网络和Internet----》网络和共享中心----》更改高级共享设置----》勾选启用网络发现
4回退到上一层，选择更改适配器设置，选中手机热点，右键选择状态， 选择详细信息，记住当前的Ipv4地址，在后面要替换localhost
5打开微信开发者工具，将刚才的IPv4地址替换所有的localhost,我这里是将host封装到一个工具包中，一改全改，大家视自己情况而定即可
6最后一步，点击预览扫码即可

首先要谈到架构，微信后台系统的模型大致理解为三层架构，接入层（proxy）、逻辑层（CGI）、存储层（后台模块）。啥意思呢？由接入层mmproxy调用逻辑层的CGI，比如摇一摇或者发消息的CGI，逻辑层再和存储层通信，比如存取账户信息，文件，地址信息等等。这是常规主流的架构没有什么特别需要说明的了，这边采用的是微服务架构，通信使用RPC框架，调用下级模块过多，就有 高扇出 问题。

我们先来理一下过载可能导致的一些现象。假设后台模块系统极限请求量是60万，我们知道当实际请求量超过这个数值就会过载，那么过载会发生什么情况？是不是发送了70万请求过来，只有60万之外的那10万请求不能被处理？答案显然不是，实际情况要比这个糟很多。很显然系统一旦过载，可能就只能正常处理20万的请求，原来的60万极限值处理能力是保不住的，甚至还有可能雪崩，直至毫无处理能力。当然，这里面的原因有很多，比如无效响应，失败重试，级联传递等等。

假如一时间好多人发送了摇一摇请求，这些请求都依次入队准备去调用寻找同摇好友的CGI并等待响应结果。但是队列很长，假设这些请求的超时时间是5秒，等待时间如果6秒过长就会导致RPC超时，一旦超时调用方可能直接关闭不再等待响应，等队列排到后执行完逻辑返回的响应调用方此时并不接收也等于是属于无效的响应了。来举个栗子，春运快到了，你挤在车站排队买车票，假设最后一班发车只有60分钟了，窝了个大叉，当你排队了半天到达售票窗口时已经用时80分钟了，这时候售票员再给你吐出一张车票已经毫无意义了，车都跑了。这也叫“无效输出”。

当然除了大部分无效的响应处理耗走了资源，别忘了还有失败重试。一般RPC框架都会设置失败重试机制，当请求得不到响应调用端会重试，如果一时间失败过多将会导致短时间内大量重试请求的发起，导致进一步过载，无疑是对本已经并无富裕的系统负载雪上加霜，滚雪球效应。

由于采用微服务架构，各模块之间的调用相互影响。由于服务依赖的复杂性当前模块的雪崩会导致上游模块的变慢，性能下降，如果此时上游模块也开始过载，继续向上级联，从而导致整个系统崩溃。怎么理解呢？假设一个餐厅里的2个厨师，A桌定了2个大菜烹饪时间很长，那么就会影响传菜员的上菜速度，传菜员要等待，假设全店传菜员有限只有2个都在等厨师出A桌的2个菜后才能去服务其他桌，这个时候就影响了整个餐厅的顾客的用餐速度，最终可能导致好几桌的顾客都吃不上菜且骂骂咧咧跑了。其实这个在Hystrix里采用了资源隔离来解决这个问题，即一个传菜员只服务于一桌，A服务员只服务A桌，B服务B桌，A慢的话就A这一桌慢，B桌的传菜员只传他B桌的菜哪怕闲着玩手机也不理其他桌。

谈完原因谈解决方法。该怎么处理呢？其实Hystrix的这套思想很好了，基本思想核心也相似，但今天主要是谈微信后台实践的解决方案。

常见的过载保护方法

1减少需求：调用端的请求限速

2避免响应超时：根据调用端超时，设置T超时时间；控制队列长度，容纳T超时时间内的请求。

调用端限速

限多了，服务器能力没有充分利用，限少了，过载问题没解决。而且过载时，响应时间会阶梯式上涨，这样超时时间就会 波动 ，队列长度难设定。虽然极限能力 绝对值 比较难找，但服务器最佳负载点容易找。所以过载保护的目标：尽量让服务端维持在最佳负载点， 让有效输出接近最佳吞吐 。

古希腊水钟

那如何维持在最佳负载点呢？水钟的启示：反馈控制系统。

如图，图中的浮子上浮，上水箱下水减速，相反如果下沉则加速上水箱下水。浮子起到了稳定液位的作用，使得中水箱的水位相对稳定，往下水箱的滴水速率自然也相对稳定，使得计时相对准确。

那么OK啦，也就搞一个像浮子一样的机制，多了及早拒绝，降低通过率，少了缓慢提升通过率。

1、通过反馈动态调整通过率：及早拒绝

根据CPU使用率和队列等待时间，控制输入，这里有个算法FastReject V1计算的是 通过率 （ 过载时 按一定概率通过请求），算法公式暂不展示，主要讲究的是快降慢升。触发降低通过率的场景比如有：比如每隔一秒统计一下队列等待时间，超过n豪秒就降低通过率，或者当前CPU使用率超过阈值（比如85%）也降低通过率。及时反馈控制，不让队列等很久等到轮到自己被处理后前端已经关闭了请求，导致无效的响应。这样请求要么超载被直接拒绝，要么是有效响应，保持原来的处理能力，不让过载雪崩。这就是出队时再判断超时还是入队时就判断的区别。记得这个在Hystrix限流熔断里叫做“降级返回”。

2、同时计算业务的优先级权重：优先服务重要业务

这有点类似早高峰的公交专用道了，由公交车优先通行。实现其实也比较简单，为每个业务（CGI）指定一个优先级（这个优先级可以由后台根据业务实际配置），每个请求带个是属于什么业务的标识，FastReject对每个业务优先级维持一个通过率，低优先级通过率降为0，开始拒绝更高优先级。比如聊天消息发送的优先级为1，上传文件为2，数字越小优先级越高。当上传文件的通过率降为0后开始降聊天消息的通过率，这样保证了优先服务重要业务。这个在Hystrix里类似服务的“优雅降级”。

这里的优先级信息传递用的是RPC COOKIE。因为RPC框架支持cookie，那就刚好借用类似>