其实想跟大家分享这套支付系统的架构已经很久了，今天总算有时间写出来了。

先说说这套系统的需求由来吧：

1. 笔者公司的游戏产品已经有几款了，每次上各种渠道都是要搭配不同的计费方式，并且每开发游戏都要重复一遍痛苦的接入sdk流程
2. 游戏的支付需要出各种报表以及统计，每个游戏单独去做对人力的消耗巨大

基于以上几点，我这边设计了统一支付系统。

这个系列一共会分两篇文章，分别对应系统的v1版和v2版，我们这一篇先从v1起介绍。

在仔细分析了国内的大多数支付sdk之后，我们梳理出游戏的支付流程大体可以实现为两类：

• 第三方sdk服务器进行支付结果通知
• 第三方sdk客户端直接返回支付结果通知，没有服务器支付结果通知。

对于调用方而言，这两种方式各有好处。

• 第一种方式更加安全，但是支付调用的时间相对较长
• 第二种方式速度更快，但是很容易被不怀好意的人破解。参见之前的文章：google支付接口被刷以及解决方案

接下来，我们来看一下我这边设计的统一支付流程。

客户端:

服务器端：

简单解释一下：

• 每次支付开始，都要让服务器生成一个订单作为此次支付的记录，订单的id即为 bill_id。订单有4中状态：订单生成，支付失败，支付成功，发货成功。
• pay_server即为统一支付系统的服务器端，考虑到调用量和方便调试，使用了简单的http协议+json+sign的方式

对于服务器内部，唯一麻烦的一点是，《等待pay_server支付结果通知》这个接口。因为这个http请求需要支持挂起，在第三方支付服务器通知了pay_server之后，pay_server 根据通知里面透传的bill_id 将订单状态修改后，再给客户端结果 ...

接着上一篇继续，前面两篇算是把从创业开始发展到今天的整个过程大体说了一遍，但是接下来的文字才是真正我想要和大家分享和探讨的。

这个话题就是：作为一个技术合伙人，职责到底应该是什么？

其实随着公司的发展，我就一直在思考这个问题：一方面是来自于担心公司技术进度失控的不安全感，一方面是来自于自己不再有太多时间编码，而带来的对自身技术能力落伍的担心。

还是按照创业的阶段来说吧。

一、创业第二阶段-队长

这个时候，公司可能就3、4个人，一个产品、一个前端、一个后端。什么技术合伙人、技术总监之类的，没必要在意这个名字，这个时候，唯一的要求就是做出产品。

而这个能力，又分两块：

1. 自己编码的能力

2. 设计架构，主导技术开发的能力

这个时候，更像一个队长。你要带领几个队员，但你自己也要冲锋。

你要能够将产品解构为代码实现，你要熟悉整个产品的研发，无论前端还是后端。

这个阶段，是非常关键的为团队打基础的时间。

在产品的实现过程中，要逐渐规划出自己的技术框架，将底层、公共逻辑拆分出来，为下一个阶段做准备。

而队长，就是要将这些东西，在这个阶段尽快沉淀、积累下来。

举个例子，服务器端语言用什么？python。web框架用什么？django ...

接着上一篇文章说吧。
在这之后，差不多快到年底吧，经过朋友的介绍认识了现在的合伙人，做产品策划和运营。
之前也只是打电话聊了一下，不能说一见如故吧，但是聊下来之后也是仔细考虑了好几天，才决定是不是要进行这样的合作。
后来当面聊了一次，决定先以比较浅的合作方式试一下，就开发现有产品的某个模块，互相也都彼此磨合一下，如果感觉不错的话就再往下走。
这样差不多搞到年后，终于决定了以技术合伙人的身份进入团队，基本形成了目前创始人团队铁三角的关系。
之后开始招人，当时还在小黑屋内，而且还在烧自己的钱，所以招人的成本和质量控制的都很严格。
不过现在想起来，当时的严格对现在的我们还是有很大的好处，当时招的同事承担了当时基本所有客户端的开发，他后来又介绍了一位朋友，也是客户端开发，也很不错，现在两人都是公司的骨干。
当然，说是以技术合伙人身份加入，其实说白了还是写代码，然而现在的自己还是很怀念那时候可以酣畅淋漓写代码的日子的。
当时工作极其的辛苦，每天都在12点之后下班，当时公司一共3个人，后来又找了俩兼职，我基本每天都是12点半开车把大家送到家，然后自己才到家。
其实现在想起来那段日子也蛮难为自己媳妇的，基本都见不到几次面。（当然现在晚上也还是很晚，只是比当时12点这种量级还是好一点了）
后来，因为政策上的一些问题，公司产品出了点问题。
我们三个合伙人决定引入投资。
因为人脉上的关系，这次的投资引入的还是蛮快的。
我们三个一块见了次投资人，其他事情基本就另外两个合伙人在跑了。
这里的事情就不细说了。
投资进来之后，公司几个月内的生存暂时不是问题，但是压力也相应而来，毕竟拿了别人的钱 ...