守株阁

junit4 junit5 特点 @BeforeClass @BeforeAll 在当前类的所有测试方法之前执行。注解在【静态方法】上。 @AfterClass @AfterAll 在当前类中的所有测试方法之后执行。注解在【静态方法】上。 @Before @BeforeEach 在每个测试方法之前执行。注解在【非静态方法】上。 @After @AfterEach 在每个测试方法之后执行。注解在【非静态方法】上。

常见的例子 MomentInterval：订单、消费、事务、退款申请 Role：购买对象、供应商、购买人、服务提供商、消费者（这些东西更偏向于元数据）、审核方、发起方。role 按照原书而言是 person 可以 associate 的一些角色，person 可以根据 role 进行一些 action。RBAC 体系即这一思想的实践。保险的干系人在元数据的设定上也是一种role。 PartyPlaceThing：Role 的具体实现：投保人、被保人、用户、商家、产品、客服。注意，这一类型几乎穷尽了所有的领域实体，也包括各种 person。 Description：订单的附属对象：消费码、数量、联系⼈、游玩人；用户的附属对象：用户 ID；商家的附属对象：商家 ID、商家名称；产品的附属对象：产品名称、产品价格、产品 ID；退款申请的附属对象：场景金额原因 架构型、彩色和领域无关的组件 四色模型.xmind 架构型 构造型即 stereotype，架构型即 archetype。 四种彩色的架构型 粉色的时刻时段（MI）架构型，粉色的时刻时段明细（MIDetail）架构型。由业...

Git基础.xmind 初始化命令 配置用户、remote 和 branch 123456789101112131415161718192021222324252627282930313233343536git config --global user.name "magicliang" # 请换成你自己的名字git config --global user.email "magicliang@qq.com" # 请换成你自己的邮箱git config --global push.default simple # 我们要求 Git 版本 1.9.5 以上git config --global core.autocrlf false # 让Git不要管 Windows/Unix 换行符转换的事git config --global --listssh git@gitlab.abcgit initgit add .git commit -m "First commit&qu...

背景 IPv4 地址枯竭 5G、IOT、SDN/NFV、云计算、边缘计算等新兴技术兴起，需要地址的终端设备变多。 NAT 技术无法支持新兴技术。 各大互联网公（国外的Google、AWS、Apple，国内的阿里、滴滴等公司）司要定期推动本公司业务的 ipv6 技术改造，网信办会定期检查，不达标的公司要问责。 改造要点 因为IP地址长度从32位变为128，文本格式从十进制数字变为十六进制（见附录1），为支持两种IP地址，包括但不限于以下改造要点: 客户端（手机APP和浏览器）缓存用户IP 后端服务根据IP做判断的业务逻辑， 比如set化、小流量。 用户IP归属地查询。 用户IP白名单、黑名单。 风控使用到IP段的策略。 存储用户IP到DB或者缓存 IPv4是32位，可以转成int或者long来存储。 IPv6是128位，不能使用long或者bigint来计算存储。 在服务接口之间传递用户IP 内网之间传递，典型的是支付、风控等。 外网之间传递，如第三方微信支付等。 日志处理 后端日志落地为IPv6后，是否有通过日志内容处理的业务逻辑。 依赖ngin...

一、亚马逊14条领导力原则 我们的领导力准则不仅仅是非常鼓舞人心的墙帷。这些准则十分有效，就像我们努力工作所取得的成果一样。无论是在讨论新项目的创意、决定应对客户问题的最佳解决方案，还是对求职者进行面试，亚马逊人每天都在使用这些准则。这是令亚马逊独具特色的一个重要因素。 顾客至尚（Customer Obsession）领导者从客户入手，再反向推动工作。他们努力地工作以赢得并维系客户对他们的信任。虽然领导者会关注竞争对手，但是他们更关注客户。 主人翁精神（Ownership）领导者是主人翁。他们会从长远考虑，不会为了短期业绩而牺牲长期价值。他们不仅仅代表自己的团队，而且代表整个公司行事。他们绝不会说“那不是我的工作”。 创新简化（Invent and Simplify）领导者期望并要求自己的团队进行创新和发明，并始终寻求使工作简化的方法。他们了解外界动态，从各处寻找新的创意，并且不局限于“非我发明”的观念。 当我们开展新事物时，我们要接受被长期误解的可能。 决策正确（Are Right, A Lot）领导者在大多数情况下都能做出正确的决定。他们拥有卓越的业务判断能力...

《提升团队的微服务落地能力》

本文讨论发布周期（release cycles）里 deployment strategy 的问题，抛开大规模部署的 big bang deployment。 滚动重启、金丝雀发布、AB testing 在 martin fowler 的博客里，金丝雀发布和滚动重启和 AB testing 并没有本质区别，都是 phased approach或者 incremental approach，是 ParallelChange 思想的实践。 当我们拥有一个新版本时： 滚动重启（rolling restart） rolling restart 会让新旧版本在环境里长时间共存，逐一使节点部署新版本，这样易于发现问题和回滚。 金丝雀发布（canary release） 而金丝雀发布同样允许新旧版本长时间共存，在逐一部署新节点的前提下，逐步利用 LB 之类的基础设施来切分用户，其策略还可以细分为： 先不给新版本，在无流量的情况下在生产环境验证 - 很多大厂的实现都忽略了这点。 尽量让内部用户先使用 - FB 之类的大厂的员工都非常多，使用一个特性开关（名字很多，比如 feature bits,...

列举环境 根据 wikipedia，工业界总是把开发环境和生产环境分离出来，中间还有若干个 stages。 结构化的发布管理允许分阶段部署（rollout），测试和在遇到问题时回滚（rollback）。 常见的环境有： 4-tier architecture is development, testing, model, production (DEV, TEST, MODL, PROD), Quality Control (QC), for acceptance testing; sandbox or experimental (EXP) Another common architecture is development, testing, acceptance and production (DTAP) Development 构造对软件的变动的环境，大多数情况下仅仅是开发者的工作站（workstation）。在这个环境里实验变更和进行单元测试。集成环境有时候也可以被认为是开发环境，在集成环境里专门对 repo 里的源代码 copy 进行构建和单元测试。 T...

CI/CD 的重要性 Martin Fowler说过，“持续集成并不能消除Bug，而是让它们非常容易发现和改正。” 持续集成和持续交付作为敏捷开发的一种最佳实践，通过包括构建、部署、测试、发布流程的自动化，实现质量内建，让质量问题可以快速发现和消除，从而提升软件交付的质量和效率。 基本策略 分支模型是CICD落地的源头，研发过程各角色间的协作方式以及研发过程内代码版本的流转方式都取决于分支模型。 首先划分环境。 划分环境后设计分支，注重开发和发布两个场景。 根据分支设计流水线，验证应该发生在全流水线里。 一般的分支模型 参考文献： 《在阿里，我们如何管理代码分支？》 《What is Trunk-Based Development?》 《提升团队的微服务落地能力》

性能测试 压测问题.xmind 性能测试的必要性 营销活动周期 首先引入一个营销活动周期的概念，它是一个闭环流程： PS：1和2之间再加一个步骤。环境改造和基础数据准备。强调必须在生产环境。 压测环境准备：需要复用真实的线上环境，压测结果和问题暴露才都是最真实情况。可通过压测流量全局识别、透传（数据进入影子区域）。 基础数据准备：以电商场景为例，构造满足大促场景的核心基础相关数据（如买家、卖家、商品信息），以线上数据为数据源，进行采样、过滤、脱敏，并保持同等量级。 阿里实际上是 2013 年才开始做全链路压测的，现在的压测周期更加智能化。可以在白天由几个人值守进行，包含以下活动： 压测环境改造 整个阿里经济体的压测环境，包括双十一压测，全部选择的是线上环境，此时需要评估： 如果要进行全链路压测，是否直接可以使用现有环境。 同一个API多次压测是否会被拦截-容易被忽略。 是否会有脏数据影响、如果有影响应该如何改造避免-必须进行的改造项目：1 识别+ 透传流量标，2 构造影子数据区域。 以上这些问题总结下来即为两类问题：业务问题和数据传递问题。问题比较明确，我们就根据...