多年后的架构感悟

Posted 2020-11-30 mybigbird

好久没写博客了，晃眼一看最近的一篇居然是2013年的。今夜无心睡眠，结合这些年自己对应用架构的一些感悟，谈谈几点体会。

一.架构是需要资源来实现的

个人觉得，这是最最核心，但是一些小白架构师最容易忽视的一点。

曾经看过几种场景，看各位同僚是否遇到：

架构师来自大厂，经验丰富，负载均衡/高可用/读写分离/缓存/队列，一顿操作猛如虎，最后骂队友二百五。

任何架构最后的实现都是人来做的，架构搭建的前提，不仅仅是看应用的场景和扩展性，还要考虑团队资源的能力和技术栈背景。通常架构师会遇到两种资源和架构的匹配方式。

1) 外部团队入场开发

这种就是所谓的外包项目。外包的好处，在于入场前，架构师/项目经理在招投标时就可以根据多家供应商的技术背景和应用实际场景做筛选，尽量匹配到更合适的技术栈和架子上去。

2) 内部团队自主研发

我曾经的团队里面，不少开发资源甚至只会写代码，没有完整部署生产机的经验... 可能在很多年经验的技术来看是无法想象的，但这就是现实。这个时候要根据成员的能力来搭架子，判断开发成员是否有相关的经验：

• 你辛苦搭的微服务，团队成员是否有相关经验？
• 你搞的Redis，团队成员是否理解内部机制?
• 你前端弄个mvc，团队成员会不会只会用jQuery操作页面元素?

这些都是需要思考的问题。(当然，这里并不是说必须完完全全按照成员的能力来搭架子，毕竟人的技术是可以通过学习成长的。如果有杠精朋友，请不要针对这里拍砖)

就像做菜，我们准备食材的时候一定要考虑厨师是否有烹饪能力，鲍鱼大闸蟹固然好吃，但并不是谁都会弄。假如最后没得吃，食客都得饿死，厨师也得滚蛋。

二.架构是可以持续改进的

笔者也曾经中途接手过一些项目，这些系统最开始的架构并不完善，可优化的点也很多，都是通过持续改进越来越好。

以一个C端的门岗机系统为例。

刚刚接手时，这个系统是一个很简单的B/S架构：后端.Net Webservice (1台服务器), 前端H5(1台服务器)嵌在门岗机里面访问，后端SqlServer数据库做了简单的读写分离(2台服务器)，在放行的时候自己写了一套队列机制。

后面实际的场景中遇到了不少问题：

1. 当业主早上上班及晚上下班时，门岗放行往往是高峰期，这时1台接口服务器的压力非常大，经过讨论后，改进为多台。

2. 两台接口服务器间需要读取业主的身份和房间信息，这些信息往往会高频访问(例如同一业主，在很接近的时间段内进进出出；门岗队员多次查询业主信息核实；)。并且以往的架构中会缓存一些信息，当应用接口服务器拆分为多台后无法共享内存中数据。ok，改进。

3. 在写入放行数据时自己开发了一套队列机制，但是后面却发现bug不断难以保证稳定性，维护成本也极高。ok，改进。

4.有一些数据，量比较大，所以必须存储在数据库中访问(例如日积月累的放行数据，门岗会经常查看)。虽然现有架构做了读写分离，但是现有频繁访问的数据与一些核心数据揉在一起，这些核心数据的保存必须保证稳定性，另外可能需要提供给其他应用使用。ok，改进。拆分出主数据，增加多个读库，并且读库实时同步。

 

后面的改进不仅于此，不再赘述，但是这个过程的核心：架构是需要结合场景持续改进的，没有一口吃出的大胖子，没有无缘无故的进化。

三.架构要结合场景，切忌过度设计

这里有一些有趣的经历，可以分享。

笔者曾经带过一个微信端企业号的开发团队，企业号的模块拆分是做得挺好的，所有应用可以单独拆分独立设计，只需要继承微信端的身份验证即可。这个企业号里面过往集成的应用来源和分类比较多，所以使用技术栈也较杂，团队也不断在做尝试。前端有用普通jQuery的，有用react的，有用vue的；后端有用.net的，有用java的；数据库oracle, mysql, sqlserver， 简直是大杂烩。

其中一次版本发布，需要新上线一个银行卡信息修改功能，由一个团队成员负责迭代，由于这个成员在其他项目使用过java的微服务，所以直接就把这一套代码和架子拷贝过来开发。(笔者也失察，打自己两耳光，:) )。 这下好，一个简单的读银行卡信息&写银行卡信息的应用，微服务的熔断/负载/网关/粒度拆分等机制都有了。然后发现项目的生产环境，并没有这么多服务器资源支持，然后这个开发人员没多久直接跑路，仓促接手的技术对这一套架构也并不熟悉，最后简单的应用模块不得不延期，新开发人员也在部署时被折磨得满头包最后不得不重写。

所以，并不是越复杂越流行的架构就越好，有时候一个简单的三层架构足以应付的，没必要搭配一套鸡肋的架子，最后发现食之无肉。

四.架构要结合开发流程

这里又要再次提起，架构师所建的这一套应用架子/开发体系，要根据团队成员的能力和迭代方式，因时因地因人取材。文章最初笔者提到了，一些团队成员甚至只会写代码，抑或是来自xx大厂，他的编码能力/对框架的理解/设计模式等等都无可挑剔，但是由于大厂的工作细分，对产品的持续集成，整体的生产高可用等并没有很强的认识。这个时候架构师不仅仅要根据系统的使用场景，也要定义好开发流程，也就是常说的工程化。

• 应用的背后设计是不是要区分为develop, qa, pre-product, product几套环境；
• 根据持续集成的方式，使用jenkins等CI工具；
• 使用常用的单元测试框架，避免开发人员代码自测不足的问题；
• 使用自动化的代码规范检查工具，发布和持续集成提交版本前检查质量(不要依赖于自己编写的冗长的编码规范了，那只会成为你Review代码后跟团队成员争论的依据)；

架构师不仅仅要圈出一个方向，带领技术团队前进，还要提供不断的支持，帮助团队克服现有的不足和困难。用架构的方式在流程中为小白提供帮助，我们不是高高在上的领导者，我们低头做事为开发人员打下手。

 

以上是笔者结合多年的全栈实践的总结，希望对初级架构狮有所启发，与老架构狮产生共鸣。