数据建模名称规范
综合 NV + DiDi + Ali 的各种命名规范。 DO（ Data Object）：与数据库表结构一一对应，通过DAO层向上传输数据源对象。 DTO（ Data Transfer Object）：数据传输对象，Service或Manager向外传输的对象。 BO（ Business Object）：业务对象。 由Service层输出的封装业务逻辑的对象。 AO（ Application Object）：应用对象。 在Web层与Service层之间抽象的复用对象模型，极为贴近展示层，复用度不高。 VO（ View Object）：显示层对象，通常是Web向模板渲染引擎层传输的对象。 POJO（ Plain Ordinary Java Object）：POJO专指只有setter/getter/toString的简单类，包括DO/DTO/BO/VO等。 Query：数据查询对象，各层接收上层的查询请求。 注意超过2个参数的查询封装，禁止使用Map类来传输。 Entity：JPA 规范下从数据持久层存储里取出来的对等对象。其实相当于 DO 。 Request：RESTful 接...
业务分析方法
背景 从 prd 出发，分析业务需求，寻找可以创造价值的方案。 业务分析的价值 全面分析用户的各项需求 告诉我们“做什么” 业务分析的目的 理解产品需求，识别业务范围 分析业务模块的重要程度、优先级 发现产品设计的不足 为后后续测试分析做准备 业务分析方法-整体过程 用不同的动作达到不同的产出。 理解 需求背景（必须） 举例：阿里巴巴账户体系 要初步阐述：1. 产生什么价值。 2. 需要解决什么问题。3. 甚至要阐明要达到什么目标（比如，基于支付宝账户体系统一账户id）。 现状分析（必须） 产品定位 现有业务架构 产品业务范围 规划业务架构**（1. 要有分期的意识，识别产品形态。 2. 要有清洗数据的方案，预测安全风险）** 识别（抽象分析建模） 业务角色（实际上就是系统交互的输入方，有多少个角色，就需要关注多少个东西） 自然人 其他系统 业务串联（为了找业务用例。业务串联就是把一堆文字描述串在一起） 业务用例（建模-业务用例图 用例是对场景的概括） 分析业务用例（建模-活动图 活动图是对用例的拆解） 提炼（进一步建模） 关键流程 由活动图的 ...
系分方法论交流笔记
分析、设计和架构的区别 系分 = 业务分析 + 系统设计 系分其实就是 Analysis + Design 业务分析才是最重要的大头 要理解： 架构约束 项目约束 要有： 权衡 选择 的过程 理解业务，要理解业务背后的东西，产出的是模型。 一步一步走，推演出来解决方案，要有方法论。 系统设计是很明确的工作了 应用设计 + 数据设计 + 技术设计 = 系统方案 要考虑的额外问题： 非功能设计：运行关注点、运维关注点、开发关注点、测试关注点。 项目约束 常见方法论 用例驱动设计 SOAD 面向服务的分析和设计 OOAD 面向对象分析和设计 DDD 领域驱动设计 DDD特别适合复杂系统。有一个以不变应万变的对象，才可以在未来承载复杂的业务演进过程。 这几种方法论可以混合使用。 需求分析与业务建模 把 prd 从薄读到厚，把文档中缺失的部分补全。 系分做 PRD 评审的时候，影响比较大的点一定要尽早确认。一些对系统变化可控，可预测的变化，可以暂时放过，后续在补充。 面向服务的业务建模 分析主业务服务，设计业务功能域，设计业务功能域边界。这个过程可能不断地螺旋式地重构。 如果用...
OOM 调查使用到的工具
JVM 性能诊断和 OOM 排查是 Java 工程师的核心技能之一。工具繁多，但核心思路只有一条：从宏观到微观，从现象到根因。操作系统工具看全局资源，JDK 命令行工具看 JVM 内部状态，Profiler 找热点方法，arthas 做精确定位——层层递进，最终锁定根因。 工具速查表 诊断场景 首选工具 备选工具 进程级 CPU/内存概览 top -Hp <pid> htop、atop JVM 内存分区使用率 jstat -gcutil <pid> jcmd <pid> GC.heap_info GC 行为分析 jstat -gc <pid> 1000 GC 日志 + GCViewer 线程堆栈快照 jstack <pid> jcmd <pid> Thread.print 堆转储 jmap -dump:live,format=b,file=dump.hprof <pid> jcmd <pid> GC.heap_dump Native Memory 追踪...
日期与时间
JSR 310 Java Date与Time API 新旧 API 的更迭 旧的 Java API 主要包括java.util.Date和java.util.Calendar 两个包的内容。这两个包的时间类型是可变的。如 Date 的实例可以通过 setYear 来产生变化。 JSR 310 中包括的日期类型主要有： 计算机时间：Instant，对应 java.util.Date，它代表了一个确定的时间点，即相对于标准Java纪元（1970年1月1日）的偏移量；但与java.util.Date类不同的是其精确到了纳秒级别。 人类时间：对应于人类自身的观念，比如LocalDate和LocalTime。他们代表了一般的时区概念，要么是日期（不包含时间），要么是时间（不包含日期），类似于java.sql的表示方式。此外，还有一个MonthDay，它可以存储某人的生日（不包含年份）。每个类都在内部存储正确的数据而不是像java.util.Date那样利用午夜12点来区分日期，利用1970-01-01来表示时间。这些类型的实例是 immutable 的，而且只能通过工厂方法创建。 时区...
使用 Truffle 来编译、安装智能合约(旧文一篇)
因为官定版本的 solidity 实在编译安装太费力了，放弃，改用 Truffle。 直接用 npm 安装： 1npm install -g truffle 创建新目录，初始化新目录： 123mkdir myprojectcd myprojecttruffle init 修改配置文件 truffle.js: 12345678910 module.exports = { networks: { development: { host: "localhost", port: 8545, network_id: "*", // Match any network id gas: 500000 } }}; 生成必须的智能合约源码和迁移脚本： 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253...
在以太坊网络上使用智能合约 solidity（旧文一篇）
因为一个并不周知的 issue，geth 客户端将不再提供 solc 编译相关功能。我们必须借助外部编译器，比如 solc/remix。 所谓 Contract，只是 Martin fowler 的书里面经常提到的一个富血的类型罢了。 注意，要用高版本的 npm，来安装 solc： 1npm install -g solc 智能合约代码： 12345678pragma solidity ^0.4.0;contract TestContract{ function multiply(uint a, uint b) returns (uint) { return a * b; }} 用 solcjs 来编译代码： 12solcjs --bin testContract.solsolcjs --abi testContract.sol 它会产生 testContract_sol_TestContract.bin 和 testContract_sol_TestContract.abi。结尾应该是 Contract ...
在Centos 6.7 上安装并使用web3（旧文一篇）
不要使用默认 gcc，会编译安装 web3失败。 12345678910111213sudo yum erase -y gcc gcc-c++ sudo yum install -y centos-release-scl sudo yum install -y devtoolset-3-toolchain scl enable devtoolset-3 bash yum remove -y nodejs curl --silent --location https://rpm.nodesource.com/setup_8.x | sudo bash - sudo yum -y install nodejs 不能使用全局安装，要尽量本地安装： 123456mkdir calc-nodenpm initnpm install web3 # 照理来说这样也应该 work，但就是不 worknpm install -g web3 --unsafe-perm=true --allow-root web3 本身是一系列 nodejs 模块的集合，包括但不限于 web3-eth 针对以太坊区...
在CentOS 6.7上用 geth 搭建以太坊私链网络的全部步骤（旧文一篇）
生成基本的路径 1mkdir -p ~/home/ethereum 如果 git 版本是 1.x，卸载旧的 git，安装最新版的 2.x 以上的 git: 1git version && yum erase -y git && yum install -y git 执行以下命令，编译以太坊客户端: 123456789yum install -y golangyum install -y gmp-develgit clone https://github.com/ethereum/go-ethereumcd go-ethereummake all# 生成基本路径mkdir -p ~/home/ethereum# 进入基本路径cd ~/home/ethereum 如果有“fatal: unable to access ‘https://github.com/ethereum/go-ethereum/’: Failed connect to github.com:443; Operation now in progress”考虑是容器的外网访问权限问题。...
如何做性能测试的问题下的答案
试着回答一下这个问题。 首先要划分系统类型：有状态还是无状态，业务系统还是存储系统。根据不同的业务场景，设立性能测试的目标：是要测 QPS，还是 TPS 还是 TPS，还是任何其他【性能】-从广义来讲，一个存储系统到底能够以多高的平均时延来管理大多的存储空间，可能也是性能的一种。 有了性能测试的目标，接下来就是拆解用例。如果把性能测试归为测试的话，测试就需要测试用例，测试用例只是用例的形式化表达。把用户的使用场景勾勒出来，把每一步拆解成的流程图或者时序图–我们已经得到了一个纸上的集成测试计划，只是没有跟性能挂上钩。 接下来就进入真正写测试用例的环节了。 我们的测试报告如果要涵盖足够立体的信息，则既要了解每一个环节/接口/API 的性能指标，又要了解整体的性能指标。 这个时候测试工具的覆盖面就很重要了。如果我们选择偏黑盒的测试工具，apache ab /JMeter，则我们的测试用例就要围绕着对外交互的 API写，也只能测到外围接口的性能。这样的测试用例写起来最简单，无需侵入任何内部代码中。 如果我们使用了 JMH 一类的工具，则可以自由编写对任何方法的测试用例。但需要对系统有非常...
