分享专业、有用、有趣的技术、产品、运营和管理知识。

任何一个优秀的互联网系统，都离不开各类研发岗位上工程师们的通力协作，而且这种协作必须是以高效的、低成本的沟通方式进行。软件开发从过去的小作坊到现在几十几百人，到现在成千上万人的同时参与，这里面如果没有一个好的协作工具，是不可能进行下去的。对于工程师来说，开发文档就是这样一个低成本、高效率的沟通工具。但奇怪的是，很多工程师都不愿意写文档，尤其是开发文档（或者说接口文档），因为他们觉得只要有技术就可以了，文档啥的有没有都无所谓。

对于同一个事务消息，在正常情况下它要被发送至少两次。这是因为在发送消息之前，TransactionMessageService就已经把消息保存到了数据库中。而在首次消费完消息后，TransactionMessageListener并没有从数据库中删掉，数据库中保存的消息，将被轮询服务AppListenerScheduleExecutor再次发送。

在有了分布式事务的解决方案、项目的需求、骨架代码和基础代码，做好了所有的准备工作之后，接下来就可以继续深入了解「核心业务」了。

好的架构其实是慢慢演变出来的，但良好的面向对象特性，一定是设计出来的。从图中可以看出，这里又为每个层次定义一个父类，并继承自BaseObject。例如BaseEntity表示所有实体类的父类，继承自BaseObject；BaseService表示所有服务类的父类，也继承自BaseObject。这样做可以将职责更加细化，可以参照Java中的集合类继承结构。

由于项目使用了MySQL、MongoDB、Redis、ActiveMQ、Nacos等中间件，这里就不一一安装了。基本骨架搭建完毕之后，下一步就可以开始充实内容了。

之前已经把分布式事务问题交代了一遍，包括两大定理、五大解决方案和一个成熟的开源框架，而咱们最终的目标是用SpringCloud实现一个实际创业项目的可靠消息最终一致性的分布式事务方案。

很多同学都知道分布式事务很好很强大，而且互联网上也有很多分布式事务的相关理论和解决办法，例如CAP、BASE、2PC、TCC、XA、最大努力通知、柔性事务等等，但这些理论全都缺少完整的实际案例作为参考指引（这里说的「实际案例」，不是指的几段代码，或者一两个类文件，而是指从数据库设计到最后可以部署的完整项目），所以好多人也就不知道该怎么结合实际业务场景来实践它们。

其实更复杂的基于规则的风控系统也都是从简单到复杂慢慢演化出来的。虽然Drools很强大，但它也不是唯一的规则引擎，还有另外两个也同样出色，它们是Groovy和Aviator。

上一节把风控实例的基础代码都撸了出来。接下来再来把核心服务代码和规则文件写出来。因为有了实体类、Dao，所以接来下就可以写服务类了。之前说过这个实例就是要实现两个目的：1、一分钟内连续访问三次以上，就会被直接封杀；2、黑名单用户登录会记录可疑事件。

就笔者个人创业经验，对小公司而言，最快最有效的风控手段可能就是「事件监控」和「黑名单」这两种了。原因就是简单好实现，而且实现成本几乎可以忽略不计。至于之前介绍的那些「标准/风控模型」，是在有了团队、技术及资金支持（也就是有钱了，有人了，可以想怎么折腾都行了）的情况下，才能着手实施的。而且「黑名单」也是基本上来源于「事件监控」。

由于运行规则总是会变来变去，而技术同学又不想每次规则变化就改一次代码然后变成地中海。也就是说，必须有一种技术手段，将活动规则和代码进行解耦，不管规则怎么变，代码都不用改。真有可以这么神奇么？——确实有一种这样的「解耦」技术，那就是「规则引擎」。所谓「规则引擎」，根据某百科的解释是：「是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。它接受数据输入，解释业务规则，并根据业务规则做出业务决策」。

有些行为（比如薅羊毛）虽然没有病毒、木马、漏洞等攻击来的直接，但是如果一直被黑灰产（羊毛党、刷单党等）长期吸血，企业生存下来的几率也会很低，而且这些也会严重影响正常用户的体验和利益。基于此，互联网平台借鉴了金融行业中的「风控」（风险控制）机制，主要是对欺诈和作弊行为采取了有针对性的应对策略，而不再像过去那样只知道救火。

之前的业务需求明确了需要区分终端的在线或离线状态。由于在Netty中，客户端与服务端连接时都会启动一个新的线程，在每个线程中都有唯一的ChannelHandlerContext对象，它是当前客户端连接的唯一通道。所以，可以利用这个唯一通道和客户端的IMEI号实现会话管理。

在实际项目的运行中，硬件并不是时时刻刻都在发送数据，而是会按照设定的时间间隔，有规律地传输。或者有些硬件终端因为故障、电源耗尽而无法继续发送数据。如果出现这样的情况，那服务端是不是就要一直保持长连接呢？打个不恰当的比方，是不是有十万名游客来到故宫旅游，就要给故宫装十万个马桶呢？

为什么明明自定义了协议消息体，却没有显示出来呢？这是因为虽然已经自定义了协议消息体，但并没有告诉Netty该如何解析——这就像给了某人一本英语书却没教他怎么学英语一样。而这种对协议的解析，就是编码/解码器的专职工作。

大多数硬件电子产品，都自带了嵌入式软件，或者说固件。这些嵌入式软件/固件基本上都是用C/C++编写的。由于这些小微电子设备资源极其有限，所以它们的通讯方式和协议也极为简单：99.99%都只支持TCP/UDP通讯协议，HTTP根本不在考虑之列。但同时，这些电子设备数量庞大，通讯频繁，尤其是大型基建设施，如水坝、核电站、火车站、塔台等设备运行状态的实时数据，尤为重要，甚至延误、丢失一秒钟的数据都会造成重大事故。由于Netty对TCP/UDP全方位的支持、良好的性能和成熟的社区，使它成为了这方面应用开发的不二选择

在摸到RPC的小院和大门（XML-RPC、JSON-RPC和gRPC）之后，就进到RPC的「家里」来做客了。招待咱们的就是Netty——一个可以代表RPC的话事人。官方对Netty的定义是：一个异步事件驱动的网络通信框架。Netty之所以这么重要，是因为XML/JSON-RPC、gRPC都有Netty的身影。不仅如此，RocketMQ、Dubbo、Hadoop、Spring5响应式编程、Elasticsearch、IoT、WebSocket等等，它们的底层实现都离不开Netty的支持。

如果说之前的XML-RPC和JSON-RPC只是Demo级别的玩具的话，那么gRPC则是真正的RPC大「门」——它是谷歌推出的高性能、开源和通用的RPC框架，它的底层由HTTP/2、Protobuf和Netty等提供技术支撑。gRPC通过IDL（Interface Definition Languagee，接口定义语言），定义可以远程调用的方法、参数和返回类型。

和（移动）互联网不同，物联网针对的主要是一些资源有限的硬件设备，比如监控探头、烟雾感应器、温湿度感应器、车载OBD诊断器、智能电表、智能血压计等。这些硬件设备既不像个人PC电脑那样拥有较为齐全的配套支持，也不像手机那样灵活、方便、可操控，它们除了能够接受输入指令以及向外输出响应数据之外，基本上就是等于是「沉默的大多数」。所以，为了实现这些「沉默」的电子设备之间的「物物相连」和「人物相连」，实现对它们的感知、识别和管理，物联网（Internet of Things）就因此而诞生了。

假设现在用户在电商平台购买了一些商品，这些商品都是来自于不同商家。商家收到订单后会把用户买的东西发物流，然后再一个个地发到用户手上。如果此时平台也给用户推送一个发货单的消息，那么这个发货单的数据该怎么「造」出来呢？

用户下单购买的商品清单肯定是一个列表，而所谓的抽检其实就是要遍历这个列表中的每个元素，然后看看有无敏感商品或刷单行为（比如连续购买了多个同类的活动商品，并且下单时间极为接近，但这里不考虑这些）。最容易想到的方法就是直接用for循环检察列表，这的确是最直接的办法，但笔者还是要重复前面讲过的：在有了简单的、容易想到的办法后，至少还要再深入思考一下还有没有别的更好的方法可以替代呢？

作为一种行为设计模式，责任链模式可以将请求沿着处理者链进行发送。收到请求后，每个处理者均可对请求进行处理，或将其传递给链上的下一个处理者。举个例子，假设用户可以在平台上下单购买商品，而且后台运营人员也有权限访问用户创建的订单。如果后续需要增加一些订单验证步骤，比如同一个IP一天内只能下单一次、通过规则引擎判断订单是否存在刷单嫌疑、判断多级缓存中的订单是否一致等等。这样的话，每次新增一些看似必要的功能都会让代码变得更加臃肿混乱，维护困难。

在GoF中对状态模式的定位是：状态模式与有限状态机的概念紧密相关，其主要思想是程序在任意时刻仅可处于几种有限的状态中。在任何一个特定状态中，程序的行为都不相同，且可瞬间从一个状态切换到另一个状态。不过，根据当前状态，程序可能会切换到另外一种状态，也可能会保持当前状态不变。这些数量有限且预先定义的状态切换规则被称为转移。

某件事情做完以后，如果需要告诉别人结果的话，要么当面告诉别人，要么就打对方电话通知对方。这种事后告诉别人结果的方法在开发里面有个专门有的名词，叫做「回调」。对于回调这个概念，稍微了解设计模式的小伙伴可能都知道哪个模式和它对应吧。

随着业务越做越大，交易量大了，老板就提了这样的需求：支付系统需要根据不同的结算模式，返利给账户：1、选择T+1结算方式的，给账户返利订单金额的0.1%；2、选择T+7结算方式的，给账户返利订单金额的0.3%。你可能会想：这不就是简单的if...else嘛，直接写代码就好了。然鹅，老板如果继续心血来潮，想搞T+2、T+3、......、T+8、T+9、......、T+30......，咋办？

所谓的模板，其实就是一种实现过程的抽象。比如，很多人在年终时都会写一份总结报告，对过去一年的计划、目标、结果等进行复盘。因为年终总结的格式比较固定，像开头致辞、中间成绩、结尾口号这些已经有现成的措辞和表格，直接抄同事的就好。自己只需要把自己负责的这部分工作汇总一下写上去就行了。这就是最常见的模板。

上一节提到过我们希望客户端的设置能够用一行代码搞定，就像这样：client.setAppID(......).setAppSecret(......).setRequest(......).setNotifyUrl(......);而且相信有些小伙伴在做项目的时候，也会发现某些引用的第三方包里面的代码也是这么写的：object.setPropertyXXX(“1”).setPropertyYYY(“2”).build();这种看起来像火车似的用一行代码设置属性的方式，就是典型的构造器模式。

现在，不管是买菜、买票、交电费还是电商网购，都已经离不开支付系统了。而且在目前的互联网应用中，不管是开发什么类型的系统，也几乎都会对接（第三方）支付系统实现订单付款。所以，了解支付系统是如何设计和运行的就显得很有必要了。而且，支付系统如果做得很耐撕，那么再去做其他的业务系统的话，技术层面能遇到的挑战就比较少了。