| 修订版本 | 修订内容 | 修订人员 | 文档类型 | 修订日期 |
|---|---|---|---|---|
| v1.0.1.* | 3AE整站介绍 | sid | -- | 2018-12-04 |
| v1.0.2.* | 3AE整站后台架构优化 | sid | -- | 2018-12-25 |
| v2.0 final | 3AE整站开发结束all-in-one | sid | -- | 2019-3-27 |
| ————— | —————————————————————————— | ————— | ————— | —————— |
版本号说明
- 版本号第四位: 修剪文档语句结构、内容布局，不计入修订版本。
- 版本号第三位: 二级模块内容、结构进行更新，计入修订版本。
- 版本号第二位: 一级模块内容、结构进行更新，计入修订版本。
- 版本号第一位: 不限于整个文档进行升级、包含的内容同时进行版本迭代，计入修订版本并生成新的文档。
修改文档名为： 1.快照版（同布更新） 2.稳定版（只维护，不更新） 3.最终版（不更新、不维护）
感谢身边的家人;
感谢南京睿实消防设备有限公司；
感谢身边的领导；
感谢带我的小哥；
感谢身边的同事；
感谢身边的朋友。
这个项目的开始主要是以下几个原因：
- 上家主子是和京东合作的跨境电商公司，由于各种问题导致散伙不做了，项目也搁置了。我不忍心丢弃那些耗费了大量心力、脑力、体力后遗留下的前端业务代码。所以想在现有基础上模仿阿里和京东的业务再造一个电商项目。
- 现任主子是一家以物联网为发展方向的智能消防设备公司。目前使用的技术栈是Srping和Netty，项目也在经历从零到一的发展阶段。另一方面我之前在北京做WEB前端，Java方面还处在学徒工阶段。因此急需要一个边学、边实践、边维护的项目来快速成长。
- 从前端技术到后台服务，需要经历大量学习编程语言、开发环境、构建工具和编程习惯的阶段。因此，在大多数人的眼里毕业一两年的程序员根本不可能在这么杂的大环境下来熟练掌握一种开发方式，更别提既做前端、又做后端的同时还能让项目的代码质量和大厂的开发标准看齐。
- 不想当将军的士兵不是一个好士兵。同理，不像当运维的测试不是一个好开发。要想成为大手子必须要经历一个给自己造轮子，让别人使用自己的轮子，最后轮子成为别人眼中的硬通货的过程。因此，个人项目的好与坏很容易看出一个程序员的编码水平和业务理解能力。它对未来个人的职业生涯也有着不可磨灭的影响。
- 个人想把所有知道的技术功能、业务、各种稀奇古怪好玩儿的轮子全部融合在个人项目里。然后给同行SHOW，展现编程能力。
基于以上原因，我在“三脚猫的功夫”下建立起了3AE(个人域名)架构项目，它会随着个人能力的成长和项目业务的完善来逐渐演变成一套大型易扩展的系统。
该工程是JAVA架构
最近也在学习如何利用Netyy框架去构建一个SOA、RPC类似dubbo这样架构
主流的架构Spring cloud
这一版都做了哪些内容，怎么想的、接下来什么打算？
内容
- 看了许多的入门java视频，然后根据我自己的工作经验建起了第一版架构方案。
- 学习了慕课网上两位大佬的java框架教程：Spring and SpringCloud。各有千秋、俯拾仰取。
- 把视频的长处融合在一起，在之前的架构基础之上进行了两次迭代，第二版Java->Spring、 第三版SpringCloud->Spring。
- 我在水潭里扑腾了两个多月，今天终于找到了一些灵感，然后建立起了第四版架构的雏形。
打算
- 先实现功能业务
- 拆分成独立模块
- 聚合分类整理成内核模块、插槽模块、业务模块。
ORM -> MVC -> RPC -> SOA
康威定律：任何组织在设计一套系统（广义概念上的系统）时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。
- 沟通的问题，会影响设计
情景：
项目大到分布到不同的地点，甚至跨时区了。协调成本会急剧增加，很可能会下意识地减少沟通，迭代的速度就会降低甚至停止变更。微服务提倡组成小团队，由小团队负责整个系统的设计和实现，团队内部可以频繁地、细粒度地沟通。业务架构总是和团队组织的架构相匹配，当把一个大的系统拆分成小的服务时，团队也会随之拆分变化。是否使用微服务不仅仅是一个技术栈的问题，而且是和团队组织结构上的管理问题。微服务的架构的问题是团队之间的运作和管理问题。
特点：
- 大量细小颗粒
- 独立开发
- 单独部署
- 分布式管理
- 每个业务是一个服务，每个服务由一个小团队来维护
服务拆分:
- 水平复制
- "数据"分区
- 功能"解耦"
从AllInOne转变到了分层和分化。原本想应用DDD驱动模型，但有些业务模块思路还不是很清晰。因此简单的拆分一下。
Spring -> Springboot -> SpringCloud 就差一个ESB
未实现功能：
- 服务发现与注册
JAVA架构
3ae-parent pom管理
3ae-channel 底层通信
3ae-common 公共函数
>====================================> core
------- 数据存储层 ------- BackEnd
3ae-pojo 对象实体
3ae-dao 数据对象
------- 数据封装层 -------
3ae-vo 视图对象
3ae-dto 传输
------- 数据操作层 -------
3ae-manager 通用业务 RPC
3ae-service B/S微服务 RPC
------- 传输结果层 -------
3ae-web 转发、参数校验
3ae-api RESTful
3ae-answer RPC
------- 生产运行层 -------
3ae-journal 日志文件
3ae-job 自动运行
------- 用户访问层 ------- FrontEnd
3ae-admin 后台管理
3ae-user 用户中心
>====================================> 服务端代理服务器 继承服务端
------- 数据操作层 ------- BackEnd
3ae-server C/S微服务,服务端服务代理
------- 用户访问层 ------- FrontEnd
3ae-portal 门户
>====================================> 客户端代理服务器 继承服务端
------- 数据操作层 ------- BackEnd
3ae-agent C/S微服务,客户端服务代理
阶段性的开发告一段落了，电商的首页内容已经完全搞定了。接下来就是netty的开发历程。
1、图片编码格式采用YUV420sp
主要使用netty框架
3ae-channel -> io.netty
根据国标BT601（标清）和BT709（高清）两种转换方式，分了模拟和数字两种。
后期可能会在这个基础之上实现图像传输。（UDP）
2、sonarqube的maven配置
mvn sonar:sonar \
-Dsonar.host.url=http://localhost:9000 \
-Dsonar.login=d9be46eadefc3bc0f5f9cde712980d51cf9053a13、配了阿里云的rdc.aliyun.com
4、更新了njrs-rd59的代码分析
5、配置了海康的SDK
6、配置了线上的markdown的预览功能
刍易-知难行易
看云-个人文档
项目从产生、迭代开发到后期维护，最后出现最终版。会经历一个很长很长的时间来完成。
然而对于一个初中级工程师来说，从最开始学习基本语法，开发流程，基础框架，养成自己的编程、编码习惯会有一个很长的“真空期”，就是感觉不到自己的编码水平在提高。这是一个相对积累技术栈的阶段。
原因一： 不管是框架选型，插件、协议、编码规范等，技术本身都会存在各自适用的场景。对于尤其是刚接触新编码的工程师，在写项目时会经历频繁的推倒再立项再推倒的过程，这是一个快速迭代的阶段。随着个人技术快速搜索学习后的成长，项目本身会出各种各样与最开始系统设计相矛盾的地方，网上也会有大量的例子来供学习和改善现有的项目，这种情况下更多是被称作DEMO。索性我爱倒腾，不厌其烦的在这个项目上重写（都不能用重构来形容）代码。一方面大量的重写使我编码水平快速增长。另一方面也使项目本身越来越笨重，导致发布一次就得等待很长时间。
原因二： 对于JAVA渐入佳境的我来说，简单地堆砌插件和功能已经无法满足我对项目业务、技术本身的追求。尤其是在看到工作好多年工程师写的高级抽象函数后，感觉自己的代码太罗里吧嗦。虽然最开始写得丰满是为了更好的可读性。但是很多模块是可以抽象出来的，可读性稍微下降所带来的效益不仅仅是代码量的减少，更多地让代码结构有了质的飞跃。就好比不再是简单地堆砌积木，更像是用胶水把堆砌好的积木粘在一起。技术细节都封装在积木里，当哪块积木出现问题时，我们把胶水烤干后用新模块儿替换掉的同时，其他的部分依然不会散架。另一方面我们也可以根据不同的技术细节选用不同类型的积木来包装。
原因三： 前段时间深入学习了SpringCloud技术栈。脑海里有很多骚操作想试一下，但由于开发工具、技术栈、最开始的技术实现想法、生产环境等方面限制，很多新的管理工具没法使用。自身技术水平的提高也导致不想再一行行改之前的面条代码了——最不像前后端分离的前后端分离项目。
原因四： 昨天看了一些前端发展内容，看到了node作为前端中间件的一种开发方式。萌生了实现前端完全分离的念头。包括后台微服务的一些服务拆分、实现方式。我想尝试一下子。再这个项目的基础上，把所有的功能全拆分成一个一个服务。服务里再拆分成一个一个积木，互相调用的同时，不仅能用Restful调用，还能使用RPC调用。这样可以尝试不同的中间件来开发不同业务。
从另一方面来讲，接下来开发的所有项目都是这个项目的子集： 电商 内容管理 办公 主机 流程 …… 我会在这个系统的基础上拆分，分类归纳。打包完善。接着尝试用不同的服务器去部署在同一台Linux上，先用docker的虚拟路由表做网路规划，自己划分异网段来管理。后期经济跟上后可能会考虑上一台高性能的ECS，使用rancher去管理。
这个项目更新就到这里，之后可能会根据我的二期开发情况对此项目进行迭代优化。
感谢大家看到这儿。
谢谢