来源：公众号 趠龙赩只
本文已收录于@招文袋导航
本文仅针对西安“一码通”反复崩溃问题进行一点纯技术的探讨分析，说的对与不对请不要打我。文中涉及到的链接地址，为了不给西安防疫造成压力，故此均做了地址路径修改处理，不可访问。本文也没有逆向思维，就是简单的数据抓包分析，下面我们开始啰嗦。
首先，我们打开西安一码通微信小程序，查看绑定域名如下：
然后通过抓包请求，我们发现以下几个问题。
第一、小程序首页的导航及图标是通过https://apps.eshiyun.i**o（万达信息股份有限公司，经分析采用的是该公司的市民云项目接口）获取，下面的资讯部分应该是一个webview的页面，请求https://ymtrh.testixi**.cn/web-***-tourism-wx/ScenicSpots?categoryId=******=******当然这种请求没有具体测试，不清楚对服务器的压力和接口请求有多大差异，一般很少这样处理小程序的接口内容。
这里面最不可思议的是还出现了一个成都市相关的链接地址，不知道是技术大意，还是有我们不知道的一些技术性联系，总之这么大的项目即便做负载均衡也不是这样“均衡”的。链接地址和截图如下：
https://tfsmy.chengdu.gov.cn/image-static/group1/**/0C/00/****.jpg
第二、最关键的是电子健康码，实现方式居然和前面的资讯部分一样，简单的说就是iframe。
正常小程序请求接口，服务器处理完数据后，返回数据，客户端生成健康码，交互的数据理论上是不超过1KB的，这样服务器的压力就会小很多，具体考验的就是算力，而现在这种实现方式还会考验服务器的带宽。之前有看到报道说西安“一码通”用到了万兆带宽，难怪！当然，我不知道之前是不是还在服务端生成二维码传过来，但是至少这个页面好歹是客户端生成二维码了，但是即便这样，作为技术人员我始终觉得小程序好像不是这样做的。
第三、在一些基础信息查询方面，比如查询apps.eshiyun.info的全国解析，发现并没有做CDN加速，应该是做了内部负载均衡。
再查询data.xa.gov.cn全国解析也是双IP，确定应该是内部做了负载均衡。
参照以上的查询分析，我们大概得知，健康码打不打的开其实和首页本身关系并不大，因为首页就提供了一个健康码链接，即便首页打不开，只要小程序链接在就能打开健康码，当然1月4日是更新过小程序的，不知道当时是否因为这个链接也是动态的，接口服务器负载能力不够，才造成的健康码链接打不开（可能健康码链接对应的服务器并没有崩掉），这个只有负责的技术才能知道。
好了，就简单分析这么多，再啰嗦一句，有人说西安这个“一码通”招标价格27万，其实，此“一码通”并非27万的那个“一码通”。
最后，祝愿西安疫情早日过去，西安加油！
