1 项目背景

所在业务在早期没有营销费用，买家购买商品的折扣优惠是由卖家提供的。全部订单的终于价格是由卖家和业务方确定的，整个购买流程非常easy。

如今此业务收受到公司重视，业务团队能申请到营销费用。业务团队能主动补贴折扣优惠。一件东西进行促销时，用户购买此物品后。由业务方出钱补贴折扣的费用。而卖家不须要考虑优惠折扣。实现这样的营销需求须要和第三方的团队合作。比如商家营销团队、账务团队。

2 项目管理

团队协作

项目開始的时候。我方向这2个团体介绍业务背景，提产品需求，开头非常顺利：业务边界范围的界定、接口交付时间、联调測试时间、系统上线时间。

1周之后获知：账务团队又一次安排了开发负责人。然后和这个开发同事沟通之后，才发现之前讨论的需求他全然不了解，然后又一次開始讨论产品需求和实现方案，结果之前定的时间点所有废弃。由于负责的同事说实现的方案非常复杂，第一次无语了。。。

然后我发開始消减产品复杂度。。。又一次定时间评审需求、确定每一个进度的时间点。

总结：核心业务假设依赖第三方的团队。在项目初期应该尽量他们沟通，确认项目初期是否有已经开展、是否有不清楚的细节。尽管在项目開始的时候又一次安排开发负责人的情况非常少。但确实存在。并且又一次评估复杂度之后。发现对deadline影响非常大。

            对于这样的问题除了项目初期尽量暴露出来之外，发生的时候，要和产品需求方又一次确定需求中是否有些模块可以折中成简单的规则，比如：每一个商家的每一个订单的转账补贴由实时结算的方式改为 每一个商家补贴日结+提供日结明细流水的方式。由于这样的方法可以继续复用账务系统现有的日结逻辑，不须要汇款系统新开发实时结算模块。

基于这个教训，我们之后和营销系统、账务系统每隔2天都会互相通报进度。分批次提供或者要求提供 API接口。在自己业务系统通过mock方式完毕全部的流程后。分批开发、联调接口，这样可以在比统一交互时间点更早的时间进行联调和自測。两方系统API接口可以并行的联调、測试、开发，充分利用时间。

測试环境不稳定：在业务主流程开发联调完毕之后，账务系统同事通知说他们的測试环境不稳定，可是我们自以为他们会将这个问题搞定，等了一天之后发现依旧不稳定。就顺便问了下他们什么时候能搞定，结果才知道：和国足踢进世界杯一样。希望渺茫。⊙﹏⊙b！

！

！之前还想再等等，假设再等下去。那就餐具了。我们果断去他们的工位上開始沟通測试方案，用一天的时间现场自測、磨合，之后開始业务測试----在聊天工具上沟通測试中的问题，之后測试非常顺利。

需求变更

在项目中。PM是不能接受需求有太大的变化----推断根据是在当前的技术实现的复杂度。而不是依赖于产品功能的描写叙述。

所以能被接受的需求变更，一般属于产品功能的简化需求。

在跨团队合作中，一个需求简单的变化，假设没有同步给合作团队，非常有可能造成项目的延期。

这样的变化即使由产品方通知了合作团队，技术团队也要再次沟通确认，合作方的技术团队非常有可能由于这个小小的需求变动将技术实现方案大改，并且不会主动通知。PM要时刻关注这样的变化，并且保证全部团队时刻了解最新的产品需求。

这次项目中，暂时决定有个功能在此活动不会被使用（业务方来不及统计数据），可是随后的活动都会被使用，可是未及时同步到位，结果遭到合作方的吐槽，说是假设这样，此版本号就能够不开发这个功能了，延期到下个版本号。

只是最后全部的功能都按时上线，\(^o^)/~。

这样的问题归根结底是一定要把沟通放在第一位。

2 系统设计

模块和耦合

做好业务边界的划分，保证新业务功能模块和当前系统的关联关系最少，易于从逻辑上或者物理结构上进行切分。独立的业务模块仅仅处理一件事件，并且将这个事情处理的非常完美。

并且易于之后应用于其它业务场景，做功能扩展也不会历史业务包袱。

健壮性

健壮性分为业务实现的健壮性和系统服务的健壮性。

业务实现的健壮性体如今业务的幂等性、事务性、容错性等方面。

和REST架构风格中POST/PUT类型接口的实现原则一样，最好每一个接口要有幂等性的特征，query类型的接口天然支持幂等性，可是ADD/UPDATE/DELETE类型的接口须要一些特征參数来实现这些原则。一个完毕的交易业务由多个子流程A、B、C等子流程组成的。

假设C流程失败了，应该怎样处理当前交易业务呢？

有2种场景：

1、  假设当前交易是另外一个交易的附属流程。由于前置条件符合业务场景，则次交易流程是不同意失败的，那么事务在这样的场景是不合适的，仅仅能通过业务状态来重试，保证终于成功。

2、  另外一种方式也非经常见：假设C失败，通过事务/分布式事务来将A、B的操作所有回滚，此次业务操作失败。

假设2种方式都是可选的，第1种方式比較合理，由于可重试的实现方式，不会由于某个流程临时性错误：数据库连接失败、线程池任务加入失败等等，而影响其它业务流程，同一时候这些接口能暴露到管理界面便于之后的人工干预、系统自己主动的补偿操作。

通过业务健壮性来保证给提供使用方的服务的终于状态肯定是符合预期结果的。

系统服务的健壮性体如今良好的错误通知和恢复策略。系统中单个节点宕机或者一段时间内服务不可用或者压力过大。不应该导致整个服务集群不可用。

所谓的Load Balance、Failover、Failback、Throttle(Sampler) 这些软硬技术策略可以发挥非常大作用。

自我监控

监控分为业务监控和系统应用环境的监控。

业务系统监控主要关注业务接口的RT/QPS、成功和失败次数，核心业务的成交量等。

在某个时间段内的假设有数据指标波动较大，有可能是某些业务接口出现故障了；或者一些偶发的错误报警也须要关注，这些偶然的也有可能是代码逻辑的bug或者。系统快达到瓶颈导致的。

系统应用环境的监控就非经常见了系统的Load、CPU、MEM、磁盘IO、网卡流量、JVM等。

管理入口

业务管理界面：之前一直强调系统的幂等性、容错性。既能够通过系统自己主动重试来达到终于一致性。也能够便于暴露接口到管理页面，由管理人员人工干预进行补偿操作或者数据订正。本次系统基本上全部的服务接口都暴露到管理上，非常easy做数据订正和业务重试。

配置项管理界面：高可配置性是一个系统可以非常easy做到服务的高可靠性、易扩展性。

通过改动配置可以停用/启用不重要的流程，启用/停用压力过大的服务。。。这次系统上线開始做活动，由于新版功能上线怕账务计算错误。通过配置暂时停止划款操作，账务总额确认通过后，才启用这个业务配置。

3 总结   

每次的项目都会有不如意的地方。在项目流程上的：沟通不顺畅、人员变动、需求被强制大改。有些是依赖的第三方系统的细节不透明，首次使用之后，常常会在遇到状况才发现某些隐藏规则