如果你喜欢我，就关注我吧，关注我后回复“1到10”的随机数，即可获得惊喜。
ヽ(✿ﾟ▽ﾟ)ノ
大家好，我是静文，今天是我许久未见的小需求系列的第一期，每一期我都会跟大家分享我在日常开发中遇到的奇怪需求，为大家提供一些解决问题的思路。那么现在就开始吧，今天是第一期，我们来聊聊微信的第三方。
什么是第三方
它的全称是第三方平台服务，我们这里简称为第三方。是微信向所有认证开发者开放的一套接口，将公众号或小程序授权给第三方后，开发者可以通过调用第三方接口为公众号或小程序提供全面的服务。
首先我们通过下图看一下一般的小程序开发模式和我们接下来要讲的基于第三方的开发模式有什么区别。
小程序开发模式的一般流程包括：
基于第三方模式的流程包括：
这是两种开发模式，看似都很顺利，基于第三方，只会有一个中间平台，但一般的小程序开发模式大部分操作都是基于人工操作。
先说一下一般小程序开发的弊端
一般的小程序开发模式都是一对一模式，需要开发者提交代码、提交试用版本、提交审核、等待微信消息通知、手动发布。审核消息和违规申诉的通知只能在微信的服务通知或小程序助手中看到。当微信消息很多的时候，这种弱小的消息通知基本上就会被淹没在海量的信息中。
小程序的发布分为三个部分：通过CI提交试用版、提交审核、发布代码。提交试用版可以通过小程序的CI包完成，我们可以把这个步骤集成到自动化发布系统中。不过提交审核和发布代码都需要登录平台才能完成。
做小程序马甲包比较麻烦，马甲包的意义在于当我们的小程序A因为平台机制问题下线的时候，需要有一个一模一样的小程序B来替代，才能维持正常的线上运营。如果采用一般的小程序开发模式，我们需要维护两套代码，处理两个小程序账号的运营。
总结一下，提交流程繁琐，通知消息弱，快速复制能力为零。如果长期只维护一个小程序，还算可行。但当小程序数量达到一定量级时，就会变得非常繁琐。
接下来我们逐个拆开模块，看看两种模式有什么区别。而第三方又会带来什么改变呢？一般小程序开发模式的人工部分，包括提交审核、发布，在违规、申诉、复用方面存在弱点。基于第三方模式，审核、发布可以改为自动，违规、申诉可以改为强提醒，复用非常方便。
第三方的好处是，我申请一个小程序之后，只需要授权给第三方就可以了。那么开发模式不变，但是审核和发布的流程可以自动化。原来提交代码、操作CI、提交审核、在微信等通知、发布的步骤，变成了提交代码、操作CI、在微信等发布成功的通知。之前的审核流程和发布流程可以完全自动化。
此外，第三方还设有违规消息审核推送机制，这样原本只能在服务通知或小程序助手中收到的消息，可以调整为推送到企业微信或钉钉，由弱消息提醒变为强消息提醒，提升即时响应速度。此外，还提供了一些附加功能，如申请试用小程序、一键插件更新、用户投诉消息推送等。
是不是听上去有点不清楚呢？我们来看下面这张图，它展示了开发一个小程序的流程。
首先开发者开发好业务之后，需要提交代码，然后进入CI，登陆平台审核，等待服务通知或者小程序开发助手通知，发布即可。经过这一套流程之后，我们就把一个小程序发布上线了。
如果我们管理多个小程序，需要不断地在它们之间切换，包括提交、审核、关注通知、确认发布等，这就需要登录不同的账号、关注不同的微信账号，这对开发者来说是一个巨大的精神负担。
如果基于第三方，我们将如何发展
首先会有一个集中的平台进行管理，包括发布系统、代码系统、通知系统、消息接收系统等基础模块。
作为业务开发人员，我们只需要将代码提交到仓库，然后在仓库中设置事件，使用事件触发CI/CD系统，然后CI/CD系统会将代码发送到代码系统中。
然后开发人员登录中台进行发布操作，设置立即发布或者手动发布，此时发布系统开始工作，提交代码进行审核。
接下来消息接收系统会等待微信发送的审核通知，然后通过通知系统向开发者发送消息。如果开发者选择立即发布，则在消息发送时直接全额发布。如果不选择，仍然需要手动发布。开发者需要做的就是提交代码、操作、登录中台选择是否自动发布（默认自动发布）。通过这三个步骤，小程序的整个发布流程在一个中台就可以完成。再也不用关注微信消息、来回切换登录账号，也不用担心每天被侵犯看不到通知。
为什么要开发第三方平台？
我目前有多个小程序需要迭代升级，其中两个代码相同，2022年至少还要开发三个小程序，简单来说就是我不可能全部管理，需要集群化管理。
功能特定要求
对于第一阶段的产品需求，我将创建以下功能
在代码需求的第一阶段，我将创建这些函数
后端逻辑
前端逻辑
工程师解决问题的时候，是靠肝脏还是靠大脑？
说白了，是要无止境地消耗自己，还是用系统来优化自己？我的选择当然是用系统来优化自己。我是一个信奉效率的人。当一个系统总是处于水分不断增加的状态时，我们如何在复杂的系统中找到解决问题的线索？你可以用爆肝的方法去梳理系统、优化系统、整顿系统，也可以用集群服务、分而治之的思维。我选择后者。