交易系统建模

平台视角

业务域

聚合根
- 管理员/商家/采购员
- 询价单
- 交易订单
- 交易对手方
- 交易时间
- 交易内容
  - 出库单/入库单
  - 库存
  - 批次
  - 数量
- 履约单
  - 物流单
  - 仓储单
  - 配送单
- 售后单
- 摊位信息
- 图片
- 简介
- 商品列表
- 广告位
- 结算单

支撑域

技术支撑
外部接入
对外服务

管理域

工单
入驻审核单

建模图片

打家劫舍（4）(2023-09-19)

打家劫舍（4）

题目

沿街有一排连续的房屋。每间房屋内都藏有一定的现金。现在有一位小偷计划从这些房屋中窃取现金。

由于相邻的房屋装有相互连通的防盗系统，所以小偷不会窃取相邻的房屋。

小偷的窃取能力定义为他在窃取过程中能从单间房屋中窃取的最大金额。

给你一个整数数组 nums 表示每间房屋存放的现金金额。形式上，从左起第 i 间房屋中放有 nums[i] 美元。

另给你一个整数 k ，表示窃贼将会窃取的最少房屋数。小偷总能窃取至少 k 间房屋。

返回小偷的最小窃取能力。

题目分析

这里的核心是找到最少能偷的K间房
设x是预设的偷窃能力
f(x)是在x的偷窃能力下，能够偷的房屋
随着x的增大，f(x)总是能保持增加或者相等
我们只需要找到这个搜索能力值，并且满足f(x)正好小于k的情况

自训练

关键词摘取（国内）

供应链保持稳定
供应链重点技术突破
稳消费

关键词摘取（国外）

粮食
人口迁徙
技术封锁

运维标准化实践

现状

运维负责的事项有如下：

维护现网机器运行状态
接收上线单，完成应用上线
对上线脚本进行审核

问题如下：

没有办法对软件提供服务工程提供保证，也就是对外无法承诺时间，对内无法有效的反馈提升软件质量
没有统一的资产管理平台，所有的资产均是通过excel交接
对于流量等缺乏管控工具，无法提供可靠的无感升级以及可能存在的升级致使的事务中断，尤其涉及金融业务

对策

首先将零散的服务器资产的表格进行汇总，然后建设运维部门的统一管控平台
对资产进行标准化编号，避免需要运维人员去主动起名字，防止不同运维人员起名不统一
替换网关，由原来nginx替换为openresty+lua方案，用以解决优雅降级+流量切换
继续迭代原有账号服务，用来打通网关服务

最终实现效果

运维需要对流量进行控制，包括不限于

能标记具体用户，要控制用户（包括不限于可能的真实环境测试账号）进入的服务器
基于流量控制，能完成优雅降级和无感应用升级

将升级变成流量切换，时间短且可控
部署全部自动化

翻新系统实践

基本情况

freemark+jsp+java14的怪异组合
有部分内部接口采用feign
大部分接口采用nacos作为profile管理以及服务注册发现
前端部分仅使用了以jquery和easyui为主的插件，工程化程度不高

需求说明

来自于上线时候的苦恼，每次更新代码总会引发未在版本规划内的前端代码提交，且升级时间较长，失败回滚时候还有cache问题

问题分析

交互代码和逻辑代码均由同一个开发人员完成，此时心智负担较大，在工期较为短的时候，非常容易造成误操作，且只有上线后才能发现
系统经历了十年左右的开发，每个开发人员有不同的技术栈喜好，例如早期约定使用Spring Cloud的早期版本，而在五年后发现Spring Cloud很多功能又要二次开发，转向了nacos为主的国产。成员变换中不习惯，有部分接口就干脆采取域名+Nginx网关直连的形式
除此之外业务系统的拧巴逻辑也是翻新的重大障碍

方案选择

经过和开发小组成员讨论，建议先从增量做起，避开旧有尚能完备运行的业务，其中最简单的是需要抽出一个专门的开发人力，进行前端框架的搭建。(目前使用vue2，开发人员易于招聘)

框架需要完成以下几个事项：

要替换掉原来依靠服务器进行状态管理的现状，将状态管理放在前端
要将功能路由管理放在前端框架进行管理
要维护一个列表，标记哪些路由是用于直接走原来的逻辑，哪些路由是新增的有前端管理的逻辑
需要后端软件新增接口用以维护新旧软件的状态（一次性开发成本）

在前端框架开发完成一个月后，选取更新频率最低的应用作为试点应用，避免与正在开发的任务同时进行

当前后端代码可以剥离完毕后，在考虑后端的技术栈提纯，不应将改造任务混杂

一些结局

成功改造了从外包厂商回收的代码
在重要业务中，成功替换了进门抬杆页面的代码
为后续的业务不中断升级铺平道路

一些好玩的近况

最近出差多，不像在家里，小朋友睡觉了还要顾着点小朋友不能吵醒他。

静下心来最近好多传闻总能扰动心绪，写写文字大概能缓解下。

疫情

消息纷纷扰扰，总有人说要放开，各种奇怪的source，各种传言。虽然在物理上我们真的完全不具备条件去做这个事情，但是满天飞的传言确确实实影响了所有人的。

大概2022年的十月份看到了个对于网络空间信息污染及扭转认知的技术性文章，大概挺有意思的，也是最近这一段时间能反复相互印证的手段。

一旦有了技术性分析，事情本身可能对于我来说更多是高一个维度的观察。

主要的手段有：
1、启用冷藏多年的账号库
2、反复投放Unknown Source Speak
3、内容在普遍意义上符合一定的诉求
4、反复多账号打榜，人为攻击社交网络体系，使得本不值得讨论的问题成为了一个讨论的问题
5、一旦出现官方辟谣，一定会转为以傻子为节点的传谣

工作

加入现在的公司应该快满两年了。贡献给公司的代码是越来越少了，大部分让我还能使用编程能力都是为了我自己的服务器。反倒是真的像车库阶段的个人电脑使用方向。工具也是初创公司才会去使用。

怎么说呢，这样分裂的感觉，又使得我更好的观察了到底所谓的技术是什么。

这两年让我锻炼出的一个基本技能就是看使用的工具链能评价出具体一个开发团队会大概需要多少开发人员，凡是声称自己公司有特别强的自我研发能力，然后发现人数队伍不匹配，大概率也就是商业吹嘘了，不会有实质性的开发能力。

游戏

出差这么多天，发现我这个新买的超薄本，性能很牛逼啊，就是内存小了点，Intel的Iris Xe能打很多以前台式才能玩的游戏了，加上20w的满血CPU，而且是稳定释放。我竟然又开始静悄悄的玩一下小时后的游戏。可惜了，我已经记不起来以前玩过的好多游戏，只能支离破碎的记得一些画面。

一点观察

关于业务调查

首先需要明确，我们调研的是什么业务。
其次应该要调研目前较为频繁的操作，必须要区分主次而不是把曾经的流程死缠烂打。边缘策略不需要太关注
最后应调研的是，不同角色的不同吐槽，然后汇总

关于会议

一个有效的会议组织，应该事前分发好资料，事中做好记录，事后做好跟踪
对于傻逼议题能有效的中断。
会议必须要有时限。

一些近况

关于技术

一般的小公司，没必要纠结上各种高大上的分布式。耗费的成本远超当初划分的成本，老老实实用单体应用做好代码切割才是正途
另一方面，觉得这里没有技术，或者说什么叫技术：最后变成了我回归了数学。即便依旧学不懂数学。

关于管理

大部分时候我们需要下属的目标与管理者的目标要一致。目标一致那么，制定计划的时候才能群策群力。
但是现在大部分时候都是，目标不那么一致，事情大概率是推动不下去的。想了很多缩减整改的方案，最终还是放弃了，费时费力还不讨好，不一定有成效。有成效也不能提升部门绩效。

关于生活

大头可爱了，也闹腾了。

证券、信息聚合系统框架与搭建（三）

证券、信息聚合系统框架与搭建

问题

现有的所有的渲染都放在客户端，服务端只有数据
客户端为了新增图表都需要更新客户端
目标用户更新客户端意图不强烈

扩大视角范围

不再只关注渲染层的事项，关注整个富客户端的架构

参考

参考后台开发组件化的趋势，做一个大而完整的软件平台

考虑到是软件平台，必须要解耦所有组件之间的直接调用关系

基础组件构成

组件注册中心
组件间通信工具（消息队列、消息总线）
本地数据库
渲染容器
与行情交易柜台对接的各容器适配器

软件组件划分

高频变动数据，低变更

原生程序开发

低频数据

使用Chromium做Web开发，降低开发成本，同时因为Web软件的天然容易更新的属性，能够在变更时候不需要客户端更新基础组件

组件Example

证券，信息聚合前端框架设计与搭建（二）

技术选型

现有的React可能比较符合需求，但react的diff&patch是O(n^3)级别的算法，这里可能会限制我们单页Component数量

UI界面的话，可以任意选用各个大厂的UI，例如ant.design（PC）ele.me（手机H5）

另外可以自然的引入React Native

但不应该绑死在React技术栈上，防止其授权失效直接导致业务下线

实现路径

早期验证业务阶段可以自行封装Component，系统内部采用封装后的Component来进行代码的编写（Wrap）

等开发中常见的工具类，常见的Class均稳定后，替换Component的内部实现，可以考虑重新通过开源的virtual dom库来实现

设立低时延展示组件

完全避开react的渲染逻辑

手动Bind数据，手动确认渲染时刻并将其渲染时机封装在Component下，避免当高频数据到来时CPU全部分配至JS引擎来处理差分数据合并而Render线程被阻塞

逐步封装Table，List等组件