用进化的思维做架构.docx

用进化的思维做架构好的架构要考虑方方面面，我想从编程语言的选型、容器选型、架构选型，庞大系统的解耦、设计的理念的进化演变这几个方面谈谈做架构的进化思维。语言选型出于公司发展、市场环境变化、产品迭代需要等原因，我们要做好语言的选择，而语言本身没有优劣好坏之分，选择哪种语言，完全看我们的环境是什么。通常选择语言要从以下几个点去考虑：团队语言选择首先要考虑能不能找到这样的团队，也就是说要在合适的时间选择一个合适的团队，团队对某种语言的驾驭能力，将是你开始及发展壮大的一个很重要的因素。成本我们做项目的时候，时间、成本、质量是考量的三个维度。用到架构里，我们就要考虑所选择的语言是不是在成本承受范围里。另外，这个成本的考量要综合，要考虑到人员培养的周期、学习的周期、团队配合的周期，以及人员流失带来的人力成本。控制对选择语言的控制力，包括团队领导对这种语言是否有理解和控制力，对其他成员学习这种语言的成本控制的力度，这些也都影响语言的选择。项目特点根据不同的项目需求，最终选择最适合这个项目的语言。在初期尽量保证语言的统一性，因为人员可调配，建议初期不用过多考虑语言在处理某方面的优势。技术健壮性技术健壮性包括文档安全、技术安全、文档的健全程度、活跃度、成熟度、是不是能一直持续更新等。这些也都是我们选择某一种语言技术的关键因素。所以要选择某个语言，我们通常要考虑到今后是否持续更新，否则就和现在很多开源项目一样逐渐销声匿迹。未来你再遇见问题的时候，可能只有自己去维护，可自己能维护这个开源框架的话，错认为还不如自己写一套。技术多样性语言的选择的时候一定要考虑多样性首先，语言多样性有利于团队持续发展和稳定，团队持续发展稳定了，公司才能持续发展和稳定；其次，语言多样性能带来更多的选择，利于实现产品合作；最后，语言多样性也是人才培养的一种方式，对整个行业有利。当然，这不是一成不变的，如果有可能的话，我们应该保证语言的统一，这样的话在初期的时候，我们的人员是可以标配的，当有小项目的时候，分出小组，可灵活组合。关键还是可控的。CTO要有这个意识：通过团队去控制语言，而不是通过语言去控制团队。学习成本出于人员培养的周期、学习的周期、团队配合的周期、人才流失的周期等成本考虑，我觉得在团队的日常建设中最好能做到平稳过渡，人员建设有梯度低层输送学习进取型人才中层输送高输出进阶型人才高层输送管理业务骨干型人才这样每个人发挥强项，互相依赖、互相配合，而且可以逐级引导。在培养团队的时候，CTO要注意高端输出型人才培养，这决定了团队在关键项目是否给力。对于 150 人到 200 人的团队，理想状态是中高端有大批的后备军，而且有几个人能够带领团队前行（一到两个人就足够了），这个团队就很稳。容器选型我个人认为，容器的选择其实比语言的选择要容易一些，主要是当你选择一个很好的容器，性能就会有一种很大的提升。这种选择的背后其实就是成本、时间、质量这三个纬度的PK。例如，公司发展到一定规范的时候，质量要求越来越高，然后对于时间的要求也越来越高，时间固定，质量固定，唯一能做的是增加成本。你想想怎么加成本能搞定这个事，可以加班、加人手、也可以增加硬件成本。未来某一天我们能否做到这一点：投了很少的时间和成本、质量却挺高，这其实就是技术创新了，这时候我们就能解决发展的痛点。通过创新方式去创造奇迹，比马跑得快的一定不是马车，所以要换角度去重新思考痛点。笔者认为长远地看，好的架构是改出来，短期地看，架构是设计出来的。中长期来看架构是边设计边改出来的。架构更多的是解决我们现有的痛点，就跟创业一样，我觉得做架构就是在做技术创业，架构设计的非常好，我们真正的能用多少东西呢？用的东西并不是特别多，所以往往设计出来的东西属于过度设计，从而导致过度开发，所以架构上，设计的成分固然重要，但长远看，其实架构是改出来的。企业的发展是从无到有、从小到大的过程，而企业产品演化的方向同样也是变化的，而且有时间和成本的限制，因此架构在前期、中期、后期需要考虑的点都不一样，前期要的是快和节约成本，尽快面市；中期用户数长上来了，就要考虑安全性、扩展性、稳定性了。所以一个合格的架构师，在我看来，应当因地制宜地选择语言，选择合适的容器和合适的架构，如果能够把团队里的人员、技术、规划、时间、成本、效率，还有幸福度等资源统一协调好，以实现工作目标，我觉得这才是一个合格的架构师。这也是我为什么固执地认为架构是一种文化，而不是单纯的技术。庞大的系统进行解耦解耦主要用的逆向思维，这一点和写游戏外挂非常相似。那么，庞大的系统是如何进行解耦的，解耦是否有规律可循，我个人的理解是要具体情况具体分析，但肯定是有规律可循的。第一步，“抽象＋分层”是对解决方案（代理模式）的整体把握，按照业务拆。举例，有一个老系统，它的软件不开源，是什么我不知道，好在这个