三年又三年，都快十年了大哥！\n\n\n \n\n\n这是一位入职腾讯近十年的架构师的思考总结，分享给各位。\n\n好的架构设计应该是简单、可进化的。\n\n简单的架构设计意味着成本低、风险低，可以这样理解：\n\n合理模块化，低耦合、大系统小做。\n合理层次化，清晰。\n可维护。\n\n可进化，我的理解是：\n\n抓住核心业务需求，系统架构在后续发展中低成本低风险地调整以适配业务的发展。比如QQ的核心需求是社交聊天，无论后续业务怎么发展，这都是其关键点，抓住这个需求去设计关系链和聊天系统，关注焦点就自然落到了可用、稳定性、可扩展、高性能上。好的架构设计，可以通过平行扩展解决一大部分数据规模和请求规模上升带来的压力。\n\n注：不要过早优化，先实现功能并尽快上线，根据监控数据对关键地方进行优化。\n\n好的服务设计是简单的，监控完善，可灰度的。\n\n服务设计，首要考虑有没有可复用的成熟可控方案，而不是马上动手去设计一个全新的方案。如果没有，再去思考如何简单设计。\n\n举例：业务后台服务设计很依赖对业务本身的理解，入口、用户量、操作量（读写比例）、数据量规模、系统的可用性要求等等。\n\n根据这些特征值，去判断选择异步/同步网络服务，多线程/多进程，数据存储是否使用NoSQL或者MySQL，MySQL是否需要cache，读写是否分离等等。\n\n监控是服务运营中非常关键的一点，我的经验是：监控业务规模，监控机器状态，监控代码的错误和异常，监控代码复杂逻辑，关键信息日志记录。做到每个上报数据，都能从中清楚服务本身是不是存在异常，应该怎么处理。\n\n灰度升级是海量后台的一个关键点。要求服务设计和发布的时候尽量不能是0和1的选择。灰度更多关注的是服务发布的风险控制上。\n\n好的代码设计是层次化、简单易于理解的。\n\n个人觉得好的代码设计应该是：\n\n代码目录结构(引用的代码库和自己写的分开)清晰，文件命名和实现的功能相匹配。\n类的设计遵循合理的层次化。\n逻辑代码命名跟其行为一致，遵循do one thing and do it well的原则，复杂的逻辑需要加上注释。\n\n评论区加入讨论，挑选一条留言送出腾讯云开发者社区周边一份！\n\n延展阅读：如何画好架构图：架构思维的三大底层逻辑\n\n鹅厂程序员面对面直播继续，记得提前预约直播～👇
云加社区约 2 分钟三年又三年，都快十年了大哥！
这是一位入职腾讯近十年的架构师的思考总结，分享给各位。
好的架构设计应该是简单、可进化的。
简单的架构设计意味着成本低、风险低，可以这样理解：
合理模块化，低耦合、大系统小做。
合理层次化，清晰。
可维护。
可进化，我的理解是：
抓住核心业务需求，系统架构在后续发展中低成本低风险地调整以适配业务的发展。比如QQ的核心需求是社交聊天，无论后续业务怎么发展，这都是其关键点，抓住这个需求去设计关系链和聊天系统，关注焦点就自然落到了可用、稳定性、可扩展、高性能上。好的架构设计，可以通过平行扩展解决一大部分数据规模和请求规模上升带来的压力。
注：不要过早优化，先实现功能并尽快上线，根据监控数据对关键地方进行优化。
好的服务设计是简单的，监控完善，可灰度的。
服务设计，首要考虑有没有可复用的成熟可控方案，而不是马上动手去设计一个全新的方案。如果没有，再去思考如何简单设计。
举例：业务后台服务设计很依赖对业务本身的理解，入口、用户量、操作量（读写比例）、数据量规模、系统的可用性要求等等。
根据这些特征值，去判断选择异步/同步网络服务，多线程/多进程，数据存储是否使用NoSQL或者MySQL，MySQL是否需要cache，读写是否分离等等。
监控是服务运营中非常关键的一点，我的经验是：监控业务规模，监控机器状态，监控代码的错误和异常，监控代码复杂逻辑，关键信息日志记录。做到每个上报数据，都能从中清楚服务本身是不是存在异常，应该怎么处理。
灰度升级是海量后台的一个关键点。要求服务设计和发布的时候尽量不能是0和1的选择。灰度更多关注的是服务发布的风险控制上。
好的代码设计是层次化、简单易于理解的。
个人觉得好的代码设计应该是：
代码目录结构(引用的代码库和自己写的分开)清晰，文件命名和实现的功能相匹配。
类的设计遵循合理的层次化。
逻辑代码命名跟其行为一致，遵循do one thing and do it well的原则，复杂的逻辑需要加上注释。
评论区加入讨论，挑选一条留言送出腾讯云开发者社区周边一份！
延展阅读：
鹅厂程序员面对面直播继续，记得提前预约直播～👇