2018年12月2日
-
13:40开始PPT，预计14:40写完第一部分， 15:20写完最终初稿
思路：分阶段
第一阶段，概览，然后是细分的结果
细分结果：
业务架构图，
初步使用
第二阶段，概览，细分结果，包括KM学习成果，详细的截图
Java标准库的系统学习
建立了一个未来3个月的学习计划
KM学习成果
vivo中间件提出的改进
工作习惯
书籍阅读
为了性能验证而写的数据生成器写代码过程中累计的库：统计文件，函数
2018年12月1日
中午12:30 调试dubbo， 调试完成或者到15:00
开始调试ads-security, 15:00（最晚）- 17:00
17:00 开始PPT
19:00 回
治大国如烹小鲜-果真如此也，一步亦不能差，现在，这告诉了我们，健壮性有多么重要
一件趣事：凌晨时段的调试，看日志是最容易犯错误的，因为0点一过，选择的日期就会变成前一天的，导致再也收不到日志更新了，这是个愚蠢的设计。
-
加班感想：可测试性，数据样本集足够大（足够挑出各种bug），敏捷性 -- 想办法把它变成清单
image.png 由于线上部署出现class加载的问题，将所有的工程合并在一起
本周：2018年11月26日 - 2018年11月30日
- 学习spring security，shiro权限管理框架
2018年11月30日
- security记录主要的工作
2018年11月30日
DMP url跳转问题申请节点dubbo修复， vivo 框架会议纪要- 晚上19:00 PPT
标签tag问题- 落地页freeze sql查询问题
- 落地页篡改相关事项，继续跟进，数据库建立
dmp接口子page是否应当从0开始-
确认广告主标签是否存在递归结构无 - ads-dsp-internla-serivc添加tx manager支持
增加测试对接文档-
验证redirectUploadTag是否会被用到-- 大概率用不到 -- 不会用到 - 下午14:10 开始布测试环境
- 测试syncAdvertiserTag
- ads-admin shiro dev环境更改成服务器地址
11月29日
- 完成测试剩余需求 （编写+测试 1个小时） -- 更正，一般是3个小时
- 再熟悉广告架构 （）
- tcp协议 （中午：10分钟）
- 完成ppt （晚上21:00-22:30）
- km资料库 （下午）
- 效果数据库架构设计完善 （30分钟）
- 时间预测，从mapper编写到其他预估 精确到半小时
2018年11月28日
数据库清洗：1.广告被冻结，但广告主未被冻结， 则相同网址的其他广告应当被冻结--> 这类广告应当输出一个报告列表,virtual_position_id应当为1- 不同类网页鉴定 -- 基于关键词的过滤
- ~~测试代理 ~~ -- 南京无可用代理
-
测试不同agent-- 重构security，使用新的checker- 完成所有效果2.8.0的开发任务
时间段：0-6 6-20 22-24基于时间的已完成
ip：
中午之前
2018年11月27日
-
建立不同时段访问的保存的结果(能力已具备，待移植到Security） -
移植security,最大限度丢弃依赖经证明是不可能的
-在security中应用新的方法，使用等价替换--经证明是不可能的 - security新增按按网址查询id列表的功能
ads dsp task使用新的任务调用
网页的内容保存主要是下面的形式：
html .html, 1.1,2.2
按后缀，使用的代理，使用的proxy，时段分类存储
2018年11月26日
加agent
2018年11月25日
首先确定一个初步的方案：批量使用nodejs分析文件，如果性能证明有问题，换用Java端粗糙的方式（其实Java端做起来不难，就是需要自己去手动搭建一个库）整理出样本库，哪些应当被下掉，哪些不应当被下掉，在KM上总结资料库。包括EVAL包含恶意代码的。
2018年11月24日
-~~ 移植ads-security到新的工程中，组件拆分，ctr备份到放到task层~~
申请git地址配置中心配置更改的测试-
security 篡改修正 ，以及整个security工程的测试--> 已测试，预计下周一下午14:30发RELEASE版本 -
内容库建设，实现文件系统和Database两种，使用统一的接口（FS已完成，DB的后面再上）
-~~ 认证接口和时效性功能~~ 文件接口，class重定义在线升级（无损升级）-
配置中心的值缓存策略，应当使用异步通知，否则程序使用就很困难。所有的变动都应当异步进行消息通知，这是标准模式。--> 使用1.3正常接收通知，因此，使用新版的配置中心接口就OK了 -
HTML网页内容爬取接口就是一个简单的get - 财报
2018年11月14日
落地页更加详细的通知信息
2018年11月12日
修复proxy(虽然是小问题，也花了一个上午的时间）
2018年11月11日
TimeRecorder--用于线程计时， 内部可声明多个时间点，report时可选择不同的格式--明天做
使用dup优化代理，探索StackMap（还是没怎么明白该怎么设置StackMap，但是理解更深一层）
更加简便的aop代理设计（避免多次getstatic，但是感觉JIT会优化这些东西的，以后可以不考虑在字节码级别优化，让编译器自己去优化）
下午：去郊外爬山
去药店买验血的试剂回来验
2018年11月10日
现在：2018年11月10日11:06:15，两个小时后，检查是否全部以url方式发送
总结项目中哪些部分在使用数据库，每个部分的使用
总结项目中使用redis的形式
javaagent和探针技术
jmock,easymock,mockito等mock框架
2018年11月9日
RabbitMQ的使用
探索怎么类方法级别的动态代理
字节码技术：cglib(底层使用asm)
Kafka的使用
学习Nginx的使用
2018年11月8日
Hystrix的各种Group或key的设计
Hystrix的使用配置，能够完成哪些应用场景，并写代码测试
昨晚确定的事情：1.封装LoopUtils 2.将最小化依赖提出，使用新版 3.封装TimeLimiter 4.开发点检表增加
学习RateLimiter的使用
学习Ehcache的使用
2018年11月7日
Hystrix部分源码和设计，从简单配置到工业级使用，包括一部分代码。（一个上午的时间）
提出部分上线点检表的内容
沟通：怎么清晰地、扼要地表达自己的意愿
沟通：怎么准确无误地获知对方的意愿
从底层，包括数据库的设计部分，重新梳理整个广告的建模模型。一切都是基于数据库的。分清楚哪些是基本表，哪些是关联表，哪些是衍生表。
确定一个规则：大多数事情应当首先被添加到清单上，然后才去执行。
Hystrix的ThreadPool的设计
2018年11月6日
会议和会议纪要
逆向推理出需要学习的知识
阅读《SOA架构》30%
共同协作上线清单的问题：至少，在我的程序中，需要改一下运行时间才能上线。这种协作的形式是：每个人都往清单里加入一部分内容，然后汇总起来。
了解服务熔断、降级、限流，进行代码的配置和测试(仅完成10%，尝试了解了Hystrix的简单使用）
了解常用的灰度策略
由技术团队维护的一份开发准则列表
知识矩阵
| 2018年11月1日~2019年2月1日目标 | |||
|---|---|---|---|
| 知识 | 初级（语法/配置/使用） | 中级（性能/探索） | 高级（设计/重构） |
| 数据库 | 100% | 50% | 20% |
| Java并发 | 100% | 30% | 20% |
| Java高级机制 | 100% | 100% | 20% |
| Commons类库 | 100% | 100% | 20% |
| log | 100% | 20% | 20% |
| Zookeeper | 100% | 100% | 20% |
| Spring | 100% | 40% | 20% |
| MyBatis | 100% | 20% | 20% |
| Redis | 100% | 40% | 20% |
| Ehcache | 100% | 20% | 20% |
| Kafka | 100% | 40% | 20% |
| Rabbit MQ | 100% | 40% | 20% |
| Dubbo | 100% | 40% | 20% |
| Netty | 100% | 40% | 20% |
| Tomcat | 100% | 40% | 20% |
| Nginx | 100% | 40% | 20% |
| Hystrix | 100% | 20% | 20% |
| 服务治理 SOA | 100% | 100% | 20% |
| 测试 | 100% | 100% | 20% |
| 性能测试 | 100% | 100% | 20% |
| 完整的互联网web项目 | 100% | 80% | 80% |
| 2018年11月 | |||
| 2018年12月 | |||
| 2019年1月 |
20%这个数字来自于 80-20 原则，系统中20%的代码决定着80%的功能。相应的，其余80%的代码则决定着其余20%的功能，这些功能你可能很少用到。如果你觉得自己需要深入一点，你可以使用 20% + 80% * 20% = 36% ~= 40% ，也就是说，再多深入了解一点其余80%中的20%。
这就要求你只关注那些非常重要的部分而不是所有部分。
项目分析
我们的目标是达成上面知识矩阵所设定的目标，因此，最好的方法是通过一个能够使用到这些技术的项目。
对于项目而言，我们首先要有基础的用户集合，即使应用构建起来，我们也还需要大量的外部访问来验证。
但是，我们无法模拟超大并发量的用户访问。因此，我们可以降低服务的质量，即人为的干预资源来造成大量访问的结果。我们的首要考量是TCP连接的数量，如果我们可以限制一段时间内TCP连接的数量，则就可以模拟任意规模的并发访问。
其次，是项目的需求分析。我们的项目不仅面向（虚拟的）目标用户，也需要满足我们开发人员验证某些设计理念和程序。
假定用户能够忍受的最长服务响应时间是t，则实际上，我们可以计算出最大支持的每秒并发量。假定服务完成的实际时间是s。 如果服务器是单线程的，则并发量是s/t。但是服务器可以多个线程，并且也可以采用分布式完成，这是Nginx需要完成的功能：反向代理。
单台服务器的并发量tps受CPU性能影响较大，每增加一个线程都会造成服务时间的一定下降，尤其是在面临锁的时候。因此，我们需要解决多线程、分布式服务的数据共享的问题。
请求被处理，由Tomcat完成；具体的处理逻辑是基于Spring容器的，因此，Spring容器是整个应用的核心组件；在应用中，我们应当产生适当的log来表明发生的事情，以便追踪某些bug或者查询某些事件；分布式服务通过rpc进行调用，dubbo可以满足这样的需求；而假如服务之间需要进行异步调用，这就是Kafka和RabbitMQ要完成的功能，当然，Kafka由于其吞吐量而著名，因此kafka还有可能用于传输大量的数据，在我们的项目中，我们暂时使用这两个消息组件用作异步通知的。处理通常是面向数据的，因此我们需要数据库作为系统的底层数据支撑，MySQL使我们的选择；但是数据库的访问速度不够快，因此，我们需要使用redis进行缓存访问；如果redis在远程服务器上，我们通常还会缓存少量的数据到本机上，这是Ehcache完成的。
最后，在整个流程中，我们需要进行不断迭代的测试，最后，还要来一个整体的性能测试。我们最终将会得到一个完整的web项目。
我们在设计中会遵循某些基本的策略，遵照流程来模拟每个阶段。
并且，我们可以设定整个设计过程的成员，要记住，这是一个团队在协作，不同的人都处在其中。我们不仅仅学习技术，也学习协作和管理。
我们在每个阶段，会使用清单来确定必须点检的项目。
首先，我们化身为用户，提出我们最原始的需求；
然后，我们化身为产品经理，对这些需求进一步细化，并且提出相应的可能；
然后，我们组建项目团队，包括项目经理，运维，基础架构支持，测试，开发人员。我们一人身兼数职，并在出任这一角色时完全负责自己的责任，这样，我们必须不断地进行个人的自我对抗。
《SOA架构》
SOA的4个特性：1.业务驱动（技术架构） 2.供应商中立 3.企业中心化 4.组合中心化
完整的web项目
账户系统
2018年11月5日（晚上）
2018年11月5日
git的使用和笔记
github的使用方法
《清单革命》--中午 50%, 晚上30分钟 70%， 下班后1个小时100%
应用清单和测试驱动开发
Spring集成测试：简单部分
《Spring的技术内幕》，晚上回去阅读
上传自己单独的jar包到common中，并且表明它是与其他工程无关的，这样一来，就能保持在github和central中包含util包。但是注意，不要包含公司的代码。
本地utils
首先在本地建立一个仓库，通过nexus本地构建即可。
它无需任何线上的仓库支持，因为只需要配置pom的上传地址即可。
《清单革命》
清单能够提高工作效率
清单能够提高团队协作的效率
清单不宜过长，且简单易行