版本管理

一、应用与其依赖

随着软件工程的发展，为了减小工程复杂度，分层和解耦越来越成为共识。应用也由庞大的单体应用进行了服务化拆分，单独拆分的微服务具备低复杂度、易升级、高伸缩性等优点。微服务间通过网络和其他微服务进行连接，组成了更大的逻辑应用。

一、背景

近期在商家内部本地部署EDI时，遇到一个问题：

1）商家内部没有不具备JSF注册中心等基础设施；

蓝绿发布和灰度发布都涉及路由的变更，而滚动发布则只需要逐次更新实例即可。

一、蓝绿发布

1）蓝绿发布过程中，新老版本不同时工作，非此即彼。

如今配置繁杂导致运维成本加剧，我结合开发中遇到的一些问题，思考了一个完善的配置中心至少应该具备一些必要的功能，以达到配置可查，可改。

必要的功能我认为应该有以下几点：

1. 配置项全量注册

最近大促前负责做系统压测，根据线上的某个具体业务场景做了Mock压测，根据压测时的一些监控数据得出了一个压测报告。

当观察到压测的数据能扛住峰值流量后，并没有去仔细压测的梯度数据是否合理。后经他人review后发现，梯度数据不符合线性规律。之后调整压测环境后（调整压测时间，调整RPC线程池数量，调整日志级别，调整Mock下游RPC线程池数量），才得出符合线性的数据。

事后反思得出，类似压测这种工作是有一个理论的期望结果的，当实践得出结果后，应该核对结果是否符合理论预期，如果不符合的话，肯定是压测的方式和环境有问题，需要进行调整。

重构，是一种修改代码以适配新的场景或需求的一种行为。重构大部分情况不是全盘否定，而是增量协定修改。此时，我们需要了解已有的代码，及重构点。从中找出三要素：1）不变的；2）修改的；3）废弃的；

此时，可以汇总重构前后的增改信息到一个图表，一个流程图等中，起到类似版本管理中Diff的功能。好处：

1）可以全部浏览此次修改的范围；

一、背景

今日公司按期开始618备战，其中一项为提应用的扩容需求。往年只是根据单量趋势预估大促单量，然后基于单量进行扩容。

今年受到“使用CPU百分位作容器缩容的参考指标”的影响，决定通过数据及一定的理论来支撑扩容需求。当然，提出的考量指标及公式可能不适合，也不严谨，但是“有而后优”，先通过这个方案划一个基线，然后再适场景调整。

一、背景

基于公司的节流政策，为了减少不必要的硬件成本，各小组开始对CPU使用率较低的应用进行缩容。大部分团队都是基于内部的火眼监控平台，重点关注和缩容CPU平均使用率较低的应用，然而CPU的平均使用率会丢失一些重要信息。于是，效能部门的人，通过监控容器的数据整理出了以周为单位的CPU百分位的及其与平均值的方差的一个报表。

二、CPU百分位与SLA

一、背景

公司最近开源节流，为了提高硬件资源使用率，组内决定多个应用混合部署到一台容器上。

二、混合部署注意事项

程序员在日常开发新的功能或重构已有功能时常会预见两种选择：
1）可预见的抽象，尽早抽象，自顶向下推进重构；
2）不可预见的抽象，持续迭代重构；
当发现了可抽象的点时，应该尽早抽象——这是基于时间和精力成本来说最优的选择。但是囿于业务不清晰或抽象能力、看不到抽象点时，此时选择踏实的实现功能，然后持续重构也是大数路径。

工程在命名时一般也遵循api和impl分离的原则（如下是实现流程的工程结构），但是不同定义的工程对api的认识其实并不是一致的。

1
2
3

my-flow
|__my-flow-api
|__my-flow-impl

1. 背景

近期重构项目的时候，不可避免的修改了包名，出现了服务无法注册，函数没有加载等问题。溯其根源是这些扫描注册的模块直接引用了类的字符串的硬编码，编译期无法检测出来。

1. 背景

最近在写一个rpc的中间层，目前主要为了屏蔽jsf两个版本的差异，并为以后兼容dubbo提供基础。

新的SPI日志框架开发完成后，便着手替换之前的日志逻辑，即用新的日志框架来重构之前的代码。在这个过程中，如果遵循正确的方法会使这个周期缩短，准确率也会提高，以下是在此次重构过程中总结的几条经验。

1. 动手之前先了解日志的业务逻辑，并统计涉及修改的类

1. 背景

最近在写新的基于SPI日志框架时，起初当判断当前没有Appender实例时，我会抛出异常来阻断系统。阳哥Review后建议“捕获日志框架的所有异常，不要影响应用的正常逻辑”。