技术心得--如何成为优秀的架构师

[借雨醉东风]

关注我，持续分享逻辑思维&管理思维； 可提供大厂面试辅导、及定制化求职/在职/管理/架构辅导；
有意找工作的同学，请参考博主的原创：《面试官心得--面试前应该如何准备》，《面试官心得--面试时如何进行自我介绍》。

博主其它经典原创：《管理心得--工作目标应该是解决业务问题，而非感动自己》，《管理心得--如何高效进行跨部门合作》，《管理心得--员工最容易犯的错误：以错误去掩盖错误》，《技术心得--如何成为优秀的架构师》 、《管理心得--如何成为优秀的架构师》欢迎大家阅读。

-------------------------------------正文----------------------------------------

原文链接

大家去面试时，相信都能随口说出，架构设计要考虑性能、可靠性、可扩展性。可是，针对项目中的细节一问，架构设计怎么考虑可靠性、性能等，很多同学都回答不好，甚至针对自己的项目，也讲得不清不楚。下面我说下在腾讯等大厂带团队做架构设计的几个原则（以我做的海量存储为示例来讲解。该存储量级为千万亿条kv记录的量级）：

 一、关键路径一定要短。数据从入口处，到落盘，这里能短就短。经过的节点越多，出问题的概率越大。以存储为例：接口层Proxy(缓存了路由)，直接把数据路由到应该落地的存储节点。关键路径就2个模块。其它作为非关键路径，即使挂了也没事，比如放全量路由的管理节点、比如数据异常时的迁移节点。当然，如果Proxy和管理节点同时出问题，会有一定的影响，但这个概率很底，而且管理节点逻辑比较简单，并且可以双机热备。

 二、非实时功能，不要集成到关键路径中。比如数据有过期功能，很多人会把删除过期数据的逻辑放到存储节点中。但当这个逻辑代码出问题的时候，或者这块逻辑需要做功能升级的时候，都需要修改存储节点。存储节点发版本越多，越容易影响现网。建议有一个外围模块，不断地去扫描过期数据并删除（或给存储节点发删除命令，直接删除担心数据多处写有一致性问题）。这样，删除逻辑即使有问题，可以让运维临时扩容解决，当然，这个模块需要重点监控。避免出现问题。

三、有状态节点双机热备。如存储节点，本身也需要写2-3份，以保证数据安全性。当一台机器出现问题时，可以快速切换到另一台机器服务。这点相信很多做架构的同学都能做到。

 四、无状态节点尽量使用容器，以做到快速扩缩容。当然，即使使用物理机，一般也能做到快速启停。

 五、对DB数据进行缓存。很多时候，DB可能会成为稳定性或性能的瓶颈。一般情况下，建议将DB数据进行缓存，而不是将DB作为关键路径。定期从DB读管理数据，并更新缓存。这样，DB不是关键路径，也不会成为性能瓶颈。

 六、做好对账功能。日志上，每个模块发送、回复一个命令，需要打印日志（但现网可以关闭，只在调试时打开）。统计上，要有每个模块每分钟（或每5分钟）接受了多少请求，平均处理延时是多少等。

 七、需要把正常错误和异常错误分开。比如存储系统中，Get数据，“数据不存在”，和“存储节点异常”都会导致Get失败。但一定要区分，一个是业务问题，一个是系统问题。

还有很多设计上要注意的点，比如优雅重启，比如CoreDump数据保存等。本次先总结到这，博主相信，还有很多未概括到的点。有兴趣的同学也欢迎私信交流。

以上是从技术上讲架构师之路。有兴趣的可以看看另一博博文：在管理上如何成为架构师。欢迎关注博主以获得后续的干货分享。