# 2018年年终总结 这一年经历了很多，哪怕在同一家公司也做了许许多多方面的事。有很多很多17年立的flag已经做完了，或者还在做。生活中有惊喜也有悲伤。更多的难受其实是来自家人的不理解，对IT行业的不了解。觉得工作一两年的程序员拿一万多的薪资都是别人家的孩子，然后逼我回南京落户找工作，拿着其他行业最低的工资标准做着码农的工作……这种感觉我不知道该怎么去形容。 之前也没怎么回顾经历，感触也是一阵一阵的。马上工作三年了，简单回顾下： 2016年，大四只身去了北京独自写简历，从无人问津到一天两三家。后来因为想让自己的人生履历华丽点儿，在大兴区政府绩效办做了几个月的行政管理。 2017年，辞掉了政府的工作，海投前端面了猎豹移动，之后回学校毕设答辩完又去面了京东。明白了自己的实力后找了一家有大佬带的小电商公司拼了近7个月。最后走的时候老板开出了一万想留我(那家公司股东拿的7千月薪)。当时的我技术水平在北京前端行业应该是15K左右的身价。 2018年，家里人让我来南京落了户，不想让我一直在北京一直漂着，说以后北京房子、户口、孩子上学、balabala……接着在南京拿着微薄的薪水干着JAVA兼前端的工作……不过我对薪资不在意，至少这个薪资我在南京不愁衣食住行。 简单回顾就到这儿，接下来进入正题： 2018年技术总结 运筹帷幄之中，决胜千里之外。 ——引子 虽然现在编程大环境还处于基本西化的状态，但是我一直想着把编程东方化，糅杂传统文化、东方哲学思想在编程里。之所以这么做应该是受到了国内各位大神前辈的影响，比如用中文编程的易语言等等，一代人影响一代人。最近才意识到大学看那么多乱七八糟书的原因。因此这篇“随笔总结”打算先用文人画的描述来引出我之前的编程态度，再结合工作这两年多来对开发大观园的实践所养成的编程态度，做一个详尽汇总。 【文人画】 “绘画中的一切都是假的，不要把绘画当真。你画这幅画的心情要比画这幅画重要，无所谓画完不画完，逸笔草草、恰到好处。它是文玩味，是无穷无尽的享受，是糅合媒材，笔、纸、墨水之间的高级游戏。” 摘出几个重点来跟实际编程做映射，如下： * 媒材—画作的载体 《====》 生产环境。 * 笔纸墨—实现画作的工具 《====》 编程语言与开发环境。 * 绘画内容—画作的样子 《====》 业务。 * 绘画心情—完成画作的心态 《====》 内在驱动力。 * 无所谓画完不画完—画作的开始与结束 《====》 完成周期。 * 恰到好处—画作的好与坏 《====》 完成情况。 【OKR考核】 “明确公司与团队的目标，以及明确每个目标达成的可衡量的关键结果，目标是设定一个定性的时间目标，关键的结果是由量化指标形式呈现的，在目标时期结束时，要对每个目标的的每个关键结果进行评估。" 再从绩效角度来一个编程映射，完全与工资挂钩的内容，如下： * 目标—任务的指标上限 《====》 代码质量指标 * 可衡量—任务的内容 《====》 代码的业务实现 * 关键结果—任务带来的效益 《====》 代码性能、终端兼容性、业务流量等 * 时间—任务完成的期限 《====》 代码工期 * 评估—任务回顾 《====》 代码复盘 * 明确目标—任务分配 《====》 根据自身情况去量化代码 简单总结: 从上面两个角度我们不难看出中式思维和西式思维的差别，同时很大程度说明了在整个历史长河上为什么东方传统文化会被西方文化侵蚀、甚至“强奸”。因此，我们要去学习历史，尊重历史，敬畏历史。另外想要长盛不衰持续下去一定要抱着空杯心态。去接受、去学习、去实践，最后才能做到发扬和传承。 【REST架构】 想了很久怎么开篇合适，最后还是觉得康威定律恰到好处： “Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)” 翻译：任何组织在设计一套系统（广义概念上的系统）时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。 -------------------------------------- < Situation > 项目大到分布到不同的地点，甚至跨时区了。协调成本会急剧增加，很可能会下意识地减少沟通，迭代的速度就会降低甚至停止变更。微服务提倡组成小团队，由小团队负责整个系统的设计和实现，团队内部可以频繁地、细粒度地沟通。业务架构总是和团队组织的架构相匹配，当把一个大的系统拆分成小的服务时，团队也会随之拆分变化。是否使用微服务不仅仅是一个技术栈的问题，而且是上升到了团队组织结构层面的管理问题。微服务的架构的问题是团队之间的运作和管理问题。 < Target > 因为目前我是把上家电商公司的前端业务代码单独拿来用java搭建restful架构从而实现个人项目。所以很多坑其实是不需要去踩的——市面上有大量的实现代码和书籍教程。但是为了使基础更加的牢固可靠，将来更从容地应对技术变革，有些流程，大量的坑还是很有必要去踩的。编程经验这样驱动我的技术成长。 < Project Flow > ORM -> MVC -> RPC -> SOA 它是一个项目从小做大肯定会经历的四个迭代阶段，即从All in one 到 业务微服务化 + ESB总线。 < DATA Flow > 一、访问主机 1\. 先去DNS服务器去把域名转换成IP地址 2\. 使用IP地址去访问目标主机 3\. 如果该主机没有启动对外的服务(默认访问80端口)，则返回无法访问目标主机 二、前端代理（假设该IP的主机启动了最复杂的网络架构） 该IP地址的主机配置了nginx服务器进行端口映射虚拟主机、或进行了反向代理 ```utf-8 同一局域网内不同子网段下启动了多台主机来执行相同的程序（负载均衡），不同的程序(PC端，WAP端)，通过轮询算法把大量请求平均分配在这些主机上。 eg: 192.168.0.1:80 (外网默认访问主机)作为网关服务，把外网请求平均转发到下面四个IP主机 192.168.0.51:8080 负载服务器 PC 192.168.0.52:8080 负载服务器 PC 192.168.0.91:8080 负载服务器 WAP 192.168.0.92:8080 负载服务器 WAP ``` 先把静态资源返回给用户，接着通过主机IP地址+端口号去访问后台服务获取API数据，最后在客户端拼装视图模型来给用户展示网站内容。 触发前端交互事件后需同时发送两个请求：一个GET请求获取静态资源(同时伪装URL),一个POST请求发送token验证并获取真实数据资源。 三、后端代理 配置了网关服务器配置，例如SpringCloud的Zuul，使用了RESTful架构进行了反向代理。 ```utf-8 同一局域网内不同子网段下启动了多台主机来执行相同的程序(负载均衡)，不同的程序(微服务)，通过轮询算法把大量请求平均分配在这些主机上。 eg: 192.168.1.1:80 (外网默认访问主机)作为网关服务，把外网请求平均转发到下面六个IP主机 192.168.1.11:8080 负载服务器 商品微服务 192.168.1.12:8080 负载服务器 商品微服务 192.168.1.21:8080 负载服务器 订单微服务 192.168.1.22:8080 负载服务器 订单微服务 192.168.1.31:8080 负载服务器 用户微服务 192.168.1.32:8080 负载服务器 用户微服务 ``` 先把redis缓存服务器里的数据封装成视图Json对象返回给客户端，如果没有缓存则访问数据库。最后生成Json的API去给前端调用。 < Layer > ## 顶层设计 网站开发其实就是下面该逻辑表达式求解的过程：[WHO] —》 [WHEN] —》 [HOW] —》 [WHAT] === [STATE] ## 功能实现 ### database设计 * 三范式和反范式 * 业务级联 ### DAO & DO DAO层主要实现RPC接口, 编写mapper * sql实现增删改查 * sql执行结果与DO层绑定 * 封装数据实体 具体技术 * proto数据转换，跨语言操作数据库 * 数据库存储过程 * redis缓存集群，消息队列 测试 * AIR模型 * 获取数据库操作结果 * 验证数据库连接、操作是否正常 ### Manager & VO & DTO Manager层主要实现RPC接口, 通用业务层 * 组合DAO层的数据为VO数据，DTO对象，与三方平台数据交互 * 第三方平台数据封装、预处理、转换异常信息 * service能力下沉，缓存处理、中间件 * 包装异常信息并上抛 * 开始记录日志 具体技术 * 枚举封装常量、异常信息 * 多态封装接口 * Slf4j日志五个级别：error/info/warn/fatal/debug 来包装错误信息 * 通过配置日志的不同级别来输出事故现场信息的logs文件(部分信息) Manager层测试 * BCDE模型 * 验证三方数据输入、dao层输出是否正确 * 根据传参返回不同的数据包、打印日志 * 响应请求结果 ### Service & VO & DTO Service层主要实现RPC接口 * Manager层拼接逻辑实现（操作接口）数据为VO、DTO对象 * 业务拼接逻辑实现（行为接口）对应VO层（方便Service返回数据的一个封装，行为结果，成功失败的原因） * 截获manager层上抛的异常信息，并输出最终日志。 * 系统性能监测 * 数据统计 * 定时任务 具体技术 * 枚举封装常量 * 多态封装接口 * 日志最终截获层，输出日志 Service层测试 * 验证数据输出是否正确 * 根据传参返回不同的数据包 * 响应请求结果 ### WEB Web层主要实现RESTful接口和请求转发 * 参数校验 * 鉴权控制 * 疲劳度控制 * 转义数据 * 处理POST请求 * 请求控制转发,Service或Server层 ### API层 API层主要实现RPC, 通过WEB层实现RESTful接口 * 返回GET请求，下沉POST请求到WEB层 * 数据过滤 * CSRF校验 * 鉴权控制 * 网关控制 * 流量控制 根据不同的业务输出不同的数据格式 ### Client层 PC、WAP、APP三端 PC Jquery-1.12.4 + CSS3 + H5 为了兼容到IE678，尽量少写花里胡哨的CSS3效果，毕竟重绘也有性能代价。必要时进行优雅降级 WAP VUE + VUEX + vue-router 【后记】 首先我不会告诉你们我写不行了，粘了好多平时写下的总结…… 感谢大家花费不少时间看我写的文章，希望各位都能有所收获 留一些彩蛋给大家： http://3ae.store 这个网站刚部署了nginx服务，打算前后端分离 http://api.3ae.store:10080/mall/order/detail/1000 接口地址，正在做端口映射 http://mall.3ae.store:10080 个人商城的首页啦。嘿嘿，希望大家喜欢 最后献上该项目的github地址： http://github.com/xiaomin1473/3aeStore