架构设计 25 不要

• 不要为了省事放弃你的职业精神与底线
• 不要在你的架构设计中出现单点
• 不要把简单事情复杂化，90% 的情况下单体应用仍然是大多数项目的首选考虑
• 不要为了使用微服务去使用微服务，只有在现实业务中组织架构的业务域明确切割后，且单体应用无法承载的情况下，才考虑微服务化
• 不要触碰分布式事务中间件(如 Seata、TDDL)，这会让你的系统难以理解，难以维护；遇到分布式事务，建议业务硬代码，如果出现大量分布式事务，则说明服务设计的不合理
• 不要认为你的系统是安全的，即使是纯内网应用，你的 RESTfuI API 仍然是脆弱的，建立合理的认证与授权机制
• 不要出现问题时才想到设计监控系统，监控系统的重要性如何强调都不为过
• 不要尝试让程序员去时刻关注应用底层细节，程序员就是要写好业务代码，你替程序员考虑越多，你越值钱
• 不要轻易尝试 DDD，因为认知不同，各层级人员难以达成共识，最后做出来的东西就是四不像
• 不要忽略数据一致性问题，设计应用程序时先考虑 AP 模型(最终一致性)还是 CP 模型(强一致、线性一致性)
• 不要高估文档的价值，文档这东西不维护就是废品，尝试通过设计简单化或技术手段实现文档自动化
• 不要过度解耦，适度耦合是良性的，可以让应用结构更简单，零合只会出现在课本中
• 不要忽略分布式架构的代价，注册中心、配置中心、服务治理、CI、CD、分布式事务会让中小团队痛不欲生
• 不要过分专注技术，应用设计前先考虑这个需求是否是必须的，在技术方案之外是否存在其他解决方式
• 不要把单元测试当成累赘，这是软件质量保证最重要环节
• 不要忽略应用的健壮性问题，非主干任务做好熔断降级，主线任务做好限流预防
• 不要认为 Redis 是可靠的，AOF 会丢失一秒数据，RDB 会丢失上一次 bgsave 之后的数据
• 不是所有场景都需要同步调用，非主线任务且返回值不敏感操作，如消息群发等任务采用异步调用 +WebHook/状态轮询更合适
• 不要迷信去中心化设计，如果未达到中心化组件的性能瓶颈，中心化设计结构更简单更容易理解，比如:中心化负载均衡器 Nginx 与去中心化 Spring Cloud Loadbalancer
• 不要刻意加入 Redis 中间件，很多情况增加 MySQLInnodb Buffer Pool 效果一样好，结构也更简单
• 不要尝试让研发与运维绑定，好的做法是提前建议内部规约，基于“开发与生产对等”策略进行设计
• 不要认为架构师是程序员的进阶版!架构师从上向下，程序员是自下向上，思考模式完全不同，这是最难的
• 不要相信前端发来的请求，后端要做好二次校对，合理运用 RedistToken 机制
• 不要照本宣科，要有质疑精神，要看应用场景。例如:Access Token+Refresh Token 纯粹的无状态方案就一定比 Redis 维护 Access Token 有状态方案好吗?
• 不要迷信“分库分表”，上古时代的产物在性能爆炸的今天兴许不再适用，基于分片的分布式关系型数据库产品是更好的选择

‍