非招标系统升级需求

满足业务需求的前提下，功能界面需要将每个功能按钮、查询条件、交互方式、以及界面上字段的类型、取数来源、排序等合理布局，便捷易用

支持各种常见类型附件（word、excel、JPG、PDF、RAR）的上传、下载、支持视频格式文件的上传、下载和存储

网页访问情况监控及报表：比如每天访问人员，实时在线人数等

要求实现无状态用户登入+实现前端动静分离+单独文件存储

开发语言

框架选择

数据库选择

中间件选型

部署方式

接口管理：提供易识别，易用性高的接口监控页面

1.响应时间：在95％的情况下，一般时段响应时间不超过1.5秒，高峰时段不超过4秒

2.业务量：估计用户数为100万人，每天登录用户数为10000左右，网络的带宽为100M带宽。系统可以同时满足10,000个用户请求，并为25,000个并发用户提供流畅访问功能,关键操作的响应时间小于10秒。

3.系统容量：支持百万级用户、支持TB级数据存储

4.资源占用率：日常业务量情况下CPU占用率<=50%;内存占用率<=50%

支持主流浏览器访问（IE8及以上、google、360、搜狗等）

支持win7、win10、苹果等操作系统

对数据输入有提示，数据有检查，防止数据异常。系统健壮性强，应该能处理系统运行过程中出现的各种异常情况，如：人为操作错误、输入非法数据、硬件设备失败等，系统应该能正确的处理，恰当的回避。要求系统7x24小时运行，全年持续运行故障停运时间累计不能超过10小时。提供数据备份和恢复功能，使得在由于系统的错误或其他原因引起系统的数据丢失或系统的数据被破坏时，能够及时恢复和还原数据。具备存储空间预警功能。

网络传递数据应经过加密。需要保证数据在采集、传输和处理过程中不被偷窥、窃取、篡改。业务数据需要在存储时进行加密，确保不可破解。

严格权限访问控制，用户在经过身份认证后，只能访问其权限范围内的数据，只能进行其权限范围内的操作。不同的用户具有不同的身份和权限，需要在用户身份真实可信的前提下，提供可信的授权管理服务，保护数据不被非法/越权访问和篡改，要确保数据的机密性和完整性。提供运行日志管理及安全审计功能，可追踪系统的历史使用情况。能经受来自互联网的一般性恶意攻击。如病毒（包括木马）攻击、口令猜测攻击等。至少99%的攻击需要在10秒内检测到

必须支持横向扩展

1.减少跨系统的交互，一个系统尽量只能CURD自己业务域的数据库，不要跨域去操作其他应用的数据。
2.尽量减少IO以及网络的访问，将多次的调用整合在一次操作中完成，尽量减少IO资源的浪费。
3.禁止在操作数据库或者外部接口时候放在循环里面，尽量做成批量接口调用。
4.系统间调用最好是只读，系统间的修改用事件或者消息来实现比较靠谱。
5.对于系统的配置文件，数据库字段修改，或者其他显示复杂逻辑修改；尽量采用insert的操作；而少采用update的操作；
6.系统必须支持横向扩展;底层数据库以及上层应用本身都需要支持扩展来满足未来业务的增长需求。
7.尽量采用基于消息【本地消息或者消息微服务】的一致性事务的解决方案。
8.系统需要有区分主次功能，对于主要功能需要加日志层面或者监控层面的告警逻辑；比如交易费金额、订单金额变动等。
9.尽量充分利用CPU的资源，可多引入线程池，让CPU的使用率最大化。
10.系统之间交互，拉的效果往往比推来的稳定性高，选择只读API，而不是读写API，写部分尽量采用事件驱动或者消息驱动。

1.尽可能在数据模型上控制业务对象的约束关系；如果通过程序逻辑去保证完整性与一致性，会存在一定的风险。
2.数据模型总的唯一性约束【比如订单号】，一定要在数据库层面得到控制；
3.尽量少用存储过程；将复杂的业务逻辑抽离到上层应用中；也就是时候尽量使用程序中的数据结构完成复杂的关系运算，避免用存储过程或者复杂的sql语句。因为应用服务器的扩展以及优化的成本往往比DB服务器的成本小的多。
4.sql语句尽量不要依据业务逻辑以及动态拼接的sql字符串，而是采用预编译的方式；否则有sql注入的风险。
5.如果主表与子表是一对一的关系，主键尽量相同。
6.数据库是各个业务系统的私有资源；其他系统对于该数据结构应该是透明的；只能通过接口和事件去访问和修改数据。

1.最好是拉对方的数据比较好；比对方推过来稳定性好；
2.异步消息处理的时候，最好先落地到本地库再进行处理；这样避免消息的丢失，以及消息队列的堆积，导致消息系统挂掉；
3.系统中只能有一种异常：处理中状态等待超时或者重试次数达到最大值。