企业官网建设流程全解析

一、概要

我从 1.2 环境安装阶段开始，对照项目配置确认依赖组件，启动核心服务，联调前后端，然后一路排到小程序登录报错，最终把问题锁定并修掉。

• 写入范围：jzo2o 项目环境准备、服务启动、ES 搜索环境与代码理解、小程序登录与修复

二、ES环境安装阶段

搜索功能，ES肯定是第一选择，因为单纯的数据库查询从能力和性能上都无法满足需求

如果要从ES中进行数据的检索，就必须保证数据库中的参与搜索的这部分数据实时同步到ES中

此功能的实现大体有下面这些方案：

• 同步双写：在程序在中同时向MySQL和ES写数据，这种方式实现简单，但是代码耦合

• 异步消息：程序在向MySQL写入数据之后，向MQ中投递消息，ES相关程序监听MQ，获取数据写入ES

• Canal监听：使用Canal监听MySQL的binlog，当发现写入操作后，立即读取到新写入的内容，并同步到ES

Canal的工作原理：

1. Canal伪装自己为MySQL的从节点，向MySQL主节点发送dump协议

2. MySQL主节点一旦收到dump请求，开始推送binlog给canal

3. Canal会接收并解析这些变更事件并解析binlog，并发送到其它服务器（比如es、redis等等）

环境目标：

1. 保证从MySQL-Canal-MQ-ES这套环境是没问题的

2. 保证serve、serve_item、serve_type表数据变化的时候，serve_sync表中的数据要同步变化

3. 保证小程序端用户可以从ES中搜索数据

这一步最重要的价值，是让我在真正启动项目之前，就已经知道自己不是在面对一个单体应用，而是在面对一个由网关、用户中心、公共能力、基础数据和多种中间件共同协作的微服务项目。如果这里没有先把依赖图谱理清，后面一旦联调报错，我就很容易在错误的层级里反复打转。

三、“端口-职责-请求路径”

项目跑起来之后，最先需要解决的不是“看见四个服务很开心”，而是必须知道这四个服务分别管什么。否则一旦请求报错，我连该看哪个模块、哪个日志都没有方向。

图 1 这次联调阶段实际启动的四个核心 Spring Boot 服务

另外还有一个很关键但非常容易忽略的点：网关里明明白白配置了多个路由规则，例如 /customer/** 会转发到 jzo2o-customer，/publics/** 会转发到 jzo2o-publics，而 /customer/open/login/common/user 这条登录接口又恰好处在网关白名单里。换句话说，登录请求本身不是先被 token 拦掉，而是确实已经往后走到了业务服务。

四、ES ：先确认依赖，再理解查询链路

因为当前章节本身就是“搜索下单”，所以我没有把 ES 当成一个孤立的中间件看待，而是把它当成业务功能的一部分去理解。从配置上看，基础服务已经显式依赖 ES 共享配置；从代码片段上看，搜索逻辑会围绕索引 serve_aggregation 构造布尔查询，再把命中结果转换成前端需要的简化 DTO。

我当时重点抓了三个参数：cityCode、keyword、serveTypeId。它们分别对应城市范围、关键词匹配和服务类型过滤。也就是说，这段搜索代码本质上不是“随便查一下”，而是在做一个有约束条件、有排序、有结果映射的正式业务搜索接口。

图 2 ES 搜索流程图：从参数进入到 DTO 列表返回

RestHighLevelClient 已经在新版本生态里被标记为弃用，但对于现有 ES 7.x 项目来说，它依然是可以继续工作的。

五、小程序登录报错

环境和服务都就位之后，我开始打开前端微信小程序做联调。结果登录按钮一点，页面直接弹出了 invalid code 的提示。这个报错非常短，但也非常关键，因为它意味着问题大概率不在普通业务逻辑，而是在微信登录链路本身。

图 3 小程序登录出错

登录报错第一轮判断

六、沿着代码往后追，把登录链路完整串起来

为了避免“感觉上像是微信问题”这种模糊判断，我直接回到代码，把小程序登录从前端一路追到了后端。前端 pages/login/index.vue 里会先执行 wx.login 拿到 res.code，再把 code、头像、昵称发到 /customer/open/login/common/user。

而在 customer 服务内部，loginForCommonUser() 并不会直接生成 token，它会先调用 wechatApi.getOpenId(code)。这个 Feign 接口再转到 publics 服务的 /inner/wechat/getOpenId，最后由 WechatServiceImpl 调用微信官方的 jscode2session 接口，去换取 openid。

图 4 微信小程序登录调用链与问题定位流程图

七、第一次修复的思路：统一到了后端那套 AppID(❌)

当时我先从后端入手，查到了 jzo2o-publics 当前正在使用的一套微信配置。于是我的第一反应很自然：既然后端已经有一套 appid 和 secret，那我就把前端也统一到这一套。从技术直觉上看，这一步并没有错，因为 code 与后端配置一致，确实是解决 invalid code 的必要条件。

但真正改完之后，微信开发者工具又弹出了另一个非常扎眼的提示：当前登录账号不是该小程序的开发者。也就是说，技术上我把链路对齐了，权限上却又撞到了墙。

图 5 第一次统一 AppID 后出现的提示：当前账号无该小程序权限

八、问题根源：前后端用了不止一套小程序身份

继续往下查之后，问题才真正清晰起来。前端工程里至少出现了三处和小程序运行有关的 appid：manifest.json 一套，project.config.json 一套，编译产物里的 project.config.json 还有一套；与此同时，后端 Nacos 中 jzo2o-publics 的微信配置又是另一套。

到这一步，我对 invalid code 的理解就完全落地了：是“微信登录临时 code 的归属小程序”和“后端用于换 openid 的小程序配置”从根上就没统一。

九、最终修复：统一到当前有权限的AppID，验证 AppSecret

既然第一次失败是因为我把前端对齐到了“当前账号无权限”的小程序，那么最终修复思路也就明确了：反过来，把前端和后端全部统一到“当前开发者账号有权限”的那一套小程序。我先把前端 manifest.json、project.config.json 和编译产物里的 project.config.json 统一到了同一个 appid，再去确认这套小程序对应的 AppSecret 是否真的可用。

这个验证不能靠猜，所以我额外做了一步非常关键的确认：直接调用微信官方 token 接口测试这组 appid + AppSecret。结果接口成功返回 access_token，说明这套配置是真实可用的。随后我把 Nacos 中 jzo2o-publics.yaml 的 tencent.wechat.app-id 和 secret 一并切到了这套配置，再提醒自己不要忘记重启 jzo2o-publics 服务，让运行中的进程真正加载新值。

十一、小总结