Java后台架构理解

最近自己搭建了一些架构，就此写一下对于后台架构的理解。

在平时工作中，总是在考虑什么样的项目结构是最合理，最实用的呢？

有人觉得能让开发人员大大降低工作重复度，使用简单，设计优美，健壮，可扩展的架构，就应当是很不错的架构，但此架构只是项目级别的。

项目一开始从单机项目转变为集群并扩展到微服务，分布式。监控中心，注册中心，配置中心，网关，熔断，降级，分库，分表，容灾，各种中间件的加入与合理搭配，部署配置docker  k8s ，逐渐形成一个庞大的架构体系，保证服务高可用的同时服务器的数量也从一台两台上升至几十台上百台，这样的项目会慢慢成长为庞大的系统体系。

架构设计大到整个系统架构的宏观，架构设计又小到每行代码的微观。

dto 的 aop自动参数校验 ，result 对象封装，代码自动生成，service，mapper，controller，serviceImpl 的合理生成，各个jar包之间的引用，在线文档生成，又到每个数据库字段类型，字段大小，统一表前缀，字段前缀，分布式锁，乐观锁，索引创建，sql执行过程分析，数据库合理设计冗余字段，日志记录，错误处理，elk等等。

代码开发规范，合理限制开发人员的代码规范，并提高开发人员对业务的各种场景的理解。保证业务逻辑模块代码高质量。限制个人随意创建包，创建类。必须严格控制包规则，类规则，代码写得好并不仅仅是代码效率高效，经典，而是要让别人能简单明了的理解意思。

理解业务之间的关系。根据每个业务之间的关系。合理解耦，在降低耦合又在代码重复度中做出取舍，并分配业务模块。独立某些功能模块的代码与文件。互不干扰。

搭建架构。有必要做到每个中间件，每一个jar包，每一个aop切面，每一个自定义注解，每一个本地事物，分布式事物执行或回滚的方案，每一个包，每一个类都做到心中有数，每一款中间件 mq nodb elk redis 都做到相当熟悉，在如何场景下如何搭建如何分配服务器资源。

性能测试，压力测试。使用什么样的容器，servlet，服务器配置，容器配置优化。 压力测试，获取项目准确的压力数据。对整个架构的性能有很好的理解。

代码质量把控。大量的低质量代码会导致整个系统的内存或者cpu居高不下，甚至有宕机的危险。可以通过 findbugs，sonarqube 等第三方静态代码监测工具。

服务器安全性的检测。更换默认端口，添加外网内网白名单，检查系统漏洞，代码逻辑导致的系统bug，制定调用接口数据加密方案。配置https加密可以防止传输过程中被抓包解析，app交互可以使用对称加密与非对称加密进行密钥生成与加密交互，或者参数签名来保证数据安全。尽可能少的开放端口号，服务器应用与服务器ssh 所有的密码高强度以防止暴力破解。或配置防暴力破解方案。

项目技术的可持续更新。根据当前市面上最新的一些高可用，并已稳定的技术做出项目迭代更新。jar包或者第三方应用漏洞更新。

sql语句执行计划审核。严格把控系统中每个sql 语句的质量。是否合理使用索引，是否合理排序占用时间与性能。尽量拆分复杂度太高的sql语句。保证sql高效。排除掉员工写出低效sql与过于复杂不可维护sql。减少sql影响行数，每次操作尽量少的修改数据行数，减少死锁产生概率。

db设计迭代记录，db权限控制。员工所持db用户最多只能查，写。不可编辑表字段，不可删库等操作，git commit 备注记录都需要做到精准，合理描述本次提交功能点，不可随意填写 commit 备注，不然容易导致后期代码查看历史却不知为什么改成此版本。

git严格控制分支，合理创建分支。大而又费时的新功能。理应创建新分支进行开发。线上急需修复bug 理应开辟新分支。 测试分支，做出一套合理分支控制项目成长的分支结构。 或项目多版本开发等。

开发人员任务合理分配。减免开发人员任务力度大小差距悬殊。导致负面情绪，进而影响系统健壮开发。 使用禅道或 Teambition 进行合理团队分工。每天lead提前合理分配任务量。

bug合理处理，对于每个系统产生的bug。应做到精准记录，并记录处理结果与流程。 严格把控每个bug的处理时间与处理的版本周期。做到每个版本更新bug数与新功能点的严格把控。紧急bug热更新。优先级低bug合理时间更新。不可频繁更新，保证系统稳定性。

测试小组的自动化测试体系。自动化测试体系虽然建设需要花费大量的人力与时间，但后期随着系统架构的发展壮大。人力测试是不可取的，效率太低，这个时候就可以充分发挥自动化测试脚本的力量。快速测试对应功能模块。以极快的效率找出，排查出当前系统部分bug。

前后端的分离。我个人觉得前后端分离现在不是趋势。而是本应当如此。前端的分离不仅可以让后端的开发人员专注接口的开发，保证接口的参数校验，接口的健壮性。而且最重要的是前端的 mvc 开发模式已经远远超越了以往的jsp，html编写模式。前端的 vue 逻辑判断越发完善，界面动画与效果。输入框的参数校验。前端已经是一个完整的体系，这个体系不是用后台的html模板引擎和一些js脚本能够代替的了的。分离之后，后台服务器专注处理数据，输出数据。提高了服务器的性能。因为处理静态资源与 html 也需要占用不少的服务器资源。

静态资源oss，直接把图片，视频，音频，文件，大量海量文件全部丢往ali oss。 并设置对应私有，ram，sts，url权限设置。上传文件直接前端传输oss。任何文件不经过后端。后端只保留资源地址与资源授权。大幅度提高后端的接口数据处理能力。专一接口处理。

微服务化，在设计系统之处就考虑到微服务化的方案，集成对应注册中心，配置中心的SDK，以便于项目部署至K8S进行横向扩展，再配合K8S的更新策略，从而达到不停机更新。

对于后期的第二代服务费体系，service mesh，虽然很多大厂早已经开始落地，但目前小企业，中小型公司基本上都还是使用的传统微服务体系。