系统架构设计标准

系统架构设计标准做了近十年的软件开发和架构设计工作，我见过太多从光鲜开始到烂尾收场的项目，刨去业务层面的原因，十有八九都栽在没有统一的系统架构设计标准上：不同的开发人员各搞一套，新接手的同事摸不着头脑，加个小功能要改半个系统的代码，一出问题全团队盯着日志找半天找不到根源，到最后宁愿推倒重写也不想维护。很多人觉得架构设计是看架构师个人水平，不需要什么标准，其实不然，一套成熟的系统架构设计标准，不是束缚创造力的条条框框，而是把行业里踩过的坑、验证过的经验整理出来，帮整个团队少走弯路，降低沟通成本，保障项目长期稳定运行的基础。接下来我就结合实际工作经验，从目标、基础要求、专项规范到落地执行，完整梳理一套可落地的系统架构设计标准。1系统架构设计标准的制定背景与核心目标讲清楚为什么要做这套标准，以及这套标准最终要达成什么效果，是所有设计规范的大前提。1.1制定背景这些年互联网行业发展很快，从早期的单体应用到现在微服务、云原生各种概念满天飞，不同背景的技术人员思路差异极大：有些开发偏爱快速出活，不考虑后续扩展；有些架构师沉迷技术，不管业务规模上来就搞过度设计；还有些团队人员流动大，老人走了新人接手，连原来的架构逻辑都理不清楚。几年前我在一个创业公司待过，前两任架构师一个偏爱单体分层，一个中途进来非要拆微服务，拆了一半没拆完，项目里既有单体的缠结，又有微服务的调用复杂度，最后维护成本比原来翻了三倍，大家都喊着要重构，结果拖了大半年都没攒出时间。说句实在话，如果那时候团队有一套统一的架构设计标准，所有人按同一个思路来，根本不会出这种乱子。所以制定一套大家都认同、符合团队实际情况的架构设计标准，是所有中大型项目开发的第一步，没有例外。1.2核心目标制定标准不是为了搞形式主义，所有标准条款都要围绕四个核心目标展开：1.2.1保障系统长期可扩展业务是一直在变的，今天做一个功能，明天大概率要加新的需求，好的架构设计要能做到加功能不改动底层核心逻辑，业务扩大了能方便升级架构，不能一扩展就要推倒重来。1.2.2降低团队协作和维护成本统一的标准意味着所有人都按同一个规则做事，接口怎么写、模块怎么拆大家都清楚，新人接手能快速上手，出问题能快速定位，不用花大量时间沟通对齐思路，也不用对着一团乱麻的代码猜原来的设计逻辑。1.2.3保障系统的安全性和稳定性系统一旦上线，稳定运行就是底线，标准就是把这些底线要求明确下来，避免因为个人疏忽留下安全或者稳定性的隐患，毕竟出一次大事故，对业务的影响可能几个月都缓不过来。1.2.4平衡技术投入和业务收益架构设计不能光看技术好不好看，还要算成本，小项目不用浪费钱搞过度设计，大项目不能省那点钱留下性能隐患，标准就是帮大家找到最合适的平衡点，不浪费资源也不留下缺口。2系统架构设计的通用基础标准讲清楚了制定标准的核心方向，接下来就具体说架构设计过程中要遵守的通用基础标准，这是所有架构都要满足的基本要求，不分项目大小和类型。2.1分层设计标准分层是架构设计最基础的方法，几乎所有系统都会用到分层，标准里对分层有三个明确要求：2.1.1分层边界必须清晰每一层的职责范围必须明确写清楚，不能出现跨层越界的情况，比如展示层只能负责页面渲染和用户交互，不能直接去操作数据库拿数据；数据访问层只能负责数据读写，不能处理业务逻辑。我刚入行的时候就见过老开发图快，前端按钮点击直接连数据库查询，当时一天就把功能做出来了，后来改需求要改数据规则，找了半天才发现这个逻辑藏在前端页面里，改完还牵一发动全身，差点把整个功能搞崩。所以边界清晰是分层的第一要求，哪怕多写几行代码，也不能乱层。2.1.2每层保持单一职责每一层只干和自己层级匹配的事，不要把不相干的逻辑塞进来，比如业务逻辑层就专心处理业务规则，不要把记录日志、生成验证码这种通用工具逻辑混进来，通用逻辑抽出去做成公共组件，这样改业务逻辑的时候不会影响通用功能，改通用功能也不会动业务逻辑。2.1.3依赖方向必须统一只能上层依赖下层，不能下层反过来依赖上层，更不能出现循环依赖。说通俗点就是，你需要别人帮你干活，你找下一层的模块，不能让下一层反过来找你要数据，绕来绕去最后变成一团死结，改任何一处都会影响所有层，到最后谁都不敢动代码。2.2模块化拆分标准分完层之后，就要对业务进行模块化拆分，这直接决定了系统后续的扩展性，拆分要遵守三个标准：2.2.1拆分粒度要适中不能太粗也不能太细，太粗的话一个模块塞了好几个完全不相关的业务，改一个功能要动整个大模块，很容易出bug；太细的话拆出来几十上百个小模块，模块之间调用关系复杂，光理清楚调用链就要花半天时间，完全是过度设计。我这些年的经验就是，按照业务域来拆最合理，一个完整的业务域做成一个模块，比如做一个面向企业的管理系统，就把用户权限、考勤管理、薪资计算、审批流程各拆成一个模块，粒度刚好，不管是扩展还是维护都方便。2.2.2模块之间必须解耦模块之间只能通过预先定义好的公开接口通信，绝对不能直接访问修改另一个模块内部的私有数据和逻辑。打个比方，你去饭店吃饭，只需要给前台点菜交钱，不用进后厨动人家的锅碗瓢盆，后厨也不用管你吃不吃辣，只要按照菜单做就行，这样哪怕后厨换了厨师，你吃饭的流程一点都不受影响，换模块也是一个道理，只要接口不变，内部怎么改都不影响别的模块。2.2.3模块内部要高内聚同一个模块里的所有功能都要围绕同一个业务目标，不能把用户登录和商品统计两个八竿子打不着的功能塞到一个模块里，不仅找的时候麻烦，改的时候也容易误改不相干的代码。高内聚和解耦放在一起，就是让模块变成一个个好用的积木，需要的时候拼起来，不需要的时候换下来，不会弄坏别的积木。2.3技术选型标准技术选型是架构设计的关键一步，选不对技术后续全是坑，选型要遵守三个标准：2.3.1匹配业务实际规模不能小业务硬上大架构，也不能大业务用小技术。我之前认识一个创业团队，项目才刚起步，预期一天也就几千个用户访问，结果上来就搭了微服务集群，搞了十几台服务器，光调试各个服务之间的调用就花了三个多月，项目上线直接延期，把投资人都惹不高兴了。反过来也不行，已经有百万级日活了，还抱着单体应用不松手，一搞活动就崩溃，用户都跑光了。所以选型第一步就是看业务现在有多大，未来一年大概会涨到多大，选刚好能满足还留一点冗余的技术，不用追求最先进，只要最合适。2.3.2匹配团队技术栈不要为了赶时髦选全团队都没人用过的冷门技术，说出去名头好听，出了问题没人会解决，连找个解决问题的帖子都找不到，最后只能连夜救火。当然也不是说不能用新技术，适当引入一两个可控的新技术做试点是可以的，但核心架构一定要用团队熟悉的技术，稳永远比新鲜重要。2.3.3优先选生态成熟的技术优先选社区活跃、有大公司背书、长期维护的技术，不要选刚出来没几个落地案例的新技术，也不要选已经没人维护的老旧技术，前者踩坑没人帮你填，后者出了安全漏洞都没人补，都是大隐患。3系统架构的专项设计标准通用基础标准是所有架构都要遵守的底线，在此之上，我们还要针对系统的核心特性，制定专项设计标准，覆盖不同维度的需求，才能让架构真正符合业务要求。3.1性能设计标准性能是用户体验的核心，不同场景有不同的性能要求，标准里明确了三个要求：3.1.1分场景设定响应时间要求面向C端用户的交互接口和页面，响应时间必须控制在500毫秒以内，最多不能超过1秒，用户多等一秒都会流失不少人；面向内部员工的后台管理系统，响应时间控制在3秒以内就可以，不用花太多成本去过度优化，把资源留给用户能感知到的地方。3.1.2并发能力预留足够冗余设计并发能力的时候，不能刚好按着当前峰值来做，一定要留至少30%以上的冗余，应对突发的流量增长，比如你搞活动的时候峰值是1万并发，就按着1.5万到2万来设计，不然突然流量涨一点，系统直接就崩了，临时扩容都来不及。3.1.3合理控制资源利用率服务器的CPU、内存、带宽这些资源，长期占用不能超过70%，留足够的缓冲空间应对突发峰值，不能为了省钱把资源占满，稍微一涨就宕机，当然也不能浪费太多资源，一半都用不到就没必要买那么好的服务器，平衡好成本和稳定性就行。3.2安全性设计标准安全是底线，出一次安全事故可能就把公司做没了，所以安全标准是红线，不能碰：3.2.1敏感数据必须加密用户的身份证信息、手机号、密码、支付信息这些敏感数据，存储的时候必须加密，传输的时候也要用加密通道，绝对不能明文存储密码，我之前听说过一个小电商网站，数据库明文存所有用户密码，数据库被拖库之后，所有用户信息泄露，最后赔了好多钱，网站也关了，这种完全是可以避免的，只要按标准做就不会出这种事。3.2.2权限遵循最小够用原则给用户开权限的时候，只给用户完成工作需要的最小权限，不能随便给超级管理员权限，比如一个普通运营只能改商品信息，不能给他删库的权限，哪怕他账号被盗了，也不会捅出大篓子。另外所有操作都要留日志，谁在什么时候改了什么东西，都要记下来，出问题能快速溯源。3.2.3常见风险必须提前拦截SQL注入、跨站脚本这些常见的攻击，框架层面就要做好拦截，不要把风险留给业务代码，同时还要定期做漏洞扫描，做好数据备份，就算真出了问题，也能快速恢复数据，不会把所有数据都丢了。3.3可维护性与可观测性设计标准很多架构师设计的时候只重视性能功能，不重视可维护性，最后苦了后续维护的开发，其实可维护性才是降低长期成本的关键，标准里明确了三个要求：3.3.1文档必须和代码同步更新架构图、接口文档、设计说明，每次改架构改接口都要同步更新，不能放着旧文档给大家看，我刚到现在这个团队的时候，接手一个老项目，文档写的接口参数和实际代码完全不一样，我对着文档调了一天接口都调不通，最后才发现文档早就过时了，害我白浪费一天时间，所以这个要求看起来是小事，实际上真的能帮大家省很多时间。3.3.2日志埋点要合理核心业务流程每个节点都要打日志，错误日志要带足够的上下文信息，出问题了能快速定位到哪一步出了错，不能什么日志都不打，出了问题不知道是哪错了，也不能什么乱七八糟的都打，一堆日志里找半天找不到有用的信息，一般来说核心流程、异常节点、第三方调用这几个地方打清楚日志就够了。3.3.3核心指标必须监控告警CPU、内存、磁盘、接口成功率、核心业务的请求量这些核心指标，必须做监控，异常了要第一时间通知到负责人，不能等用户找上门来投诉了，我们才知道系统崩了，提前十分钟发现问题，就能少影响很多用户，少很多麻烦。3.4扩展性设计标准业务一直在增长，架构也要能跟着变，所以扩展性是架构设计的核心要求：3.4.1预留业务扩展点设计核心流程的时候，要把可变的部分抽出来做成扩展点，比如你做支付功能，现在只接了微信和支付宝，以后要接别的支付方式，只要加个新的扩展模块就行，不用改核心的订单逻辑，这样加新功能的速度快很多，也不容易出bug。3.4.2预留架构演进空间现在业务小，做单体应用没问题，但设计的时候就要按照未来要拆微服务的思路拆分模块，把边界划清楚，不能等业务长大了要拆微服务，才发现所有模块都缠在一起，根本拆不动，最后只能推倒重写，浪费大量时间精力。4架构设计标准的评审与落地执行标准有了设计层面的标准，还要有落地执行的标准，不然再好的标准都是放在文档里落不了地的废纸。4.1分级评审标准不是所有项目都要搞一样的评审，按项目大小分级评审，提高效率：4.1.1小型内部项目比如团队内部用的小工具、内部管理的小功能，只需要架构师和项目开发负责人评审就行，确认符合基础标准就可以开工，不用兴师动众浪费大家时间。4.1.2中型业务项目面向外部用户的核心业务项目，要拉上产品、开发、测试、运维四个角色一起评审，产品确认符合业务需求，开发确认设计可实现，测试确认可测试，运维确认能部署能维护，每个环节都对齐了，才能开工。4.1.3公司级大型项目公司核心的大型项目，除了内部团队评审，还要邀请公司的资深架构师或者外部行业专家一起评审，把所有可能的风险、潜在的坑都提前找出来，避免走大方向的错误。4.2迭代更新标准标准不是一成不变的，要跟着业务和技术发展迭代：4.2.1架构设计要定期复盘项目上线之后，每隔一段时间就要复盘一次架构，看看现在的架构是不是符合当前业务的需求，有没有哪里不符合标准，有问题及时调整，不要等问题堆成山了再重构。4.2.2标准本身也要定期更新我们团队现在每年都会更新一次架构设计标准，把这一年大家踩的新坑、积累的新经验加进去，把已经过时的不适合当前情况的要求删掉，标准是服务于团队的，不是让团队服务于标准。4.3团队协作标准制定标准的时候要听一线开发和运维的意见，不能架构师拍脑袋定规矩，毕竟实际落地干活的是一线同学，定出来的标准不好用，大家自然不会遵守。标准也不是用来卡人的，是用来帮大家少踩坑的，遇到特殊情况，只要团队评审认可，