标签：修改   项目   现在   超过   负责人   案例   bsp   很多   中间   

最近几年写博客确实写得少了，初出茅庐的时候什么都愿意去写，现在写一点东西之前会反复斟酌是否有价值。工作十几年了，做了N多个互联网系统，业务涉及教育、游戏、电商、O2O、P2P，算是各种类型的互联网系统都摸过，多少有一些心得，架构方面的文章网上很多很多，有些是说一些方法论，有些是说一些具体的案例，感觉自己想分享的东西和别人已分享的是有点不同的，还是应该留下点什么。在这里我更多想分享一下搭建一套完整的互联网系统架构方面一些具体的实践心得，大概会从这几个方面来写：

1. 各种废话的闲聊和吐槽
2. 屡试不爽的架构三马车：介绍一个简单实用的可扩展的互联网架构
3. 相辅相成的存储四件套：介绍一下个人比较喜欢的一个存储组合以及适用场景
4. 简单好用的监控六兄弟：介绍监控方面一直在用的一些工具以及强调监控的重要性
5. 不断耕耘的基础中间件：中后期的项目需要有完善的基础中间件，这里进行逐一介绍
6. 令人头痛的飞机换引擎：有的时候需要对高速发展的项目进行重构，这里分享一些经验
7. 高并发架构到底是什么：高并发架构优化在优化哪些方面，具体会做一些什么事呢？
8. ……（想到了再补充吧）

很多项目起步的时候都会以一个All-In-One的项目起步，使用一套MVC框架，对外提供数据的Controller、包含业务逻辑的Service、访问数据库的DAL、定时任务，所有的东西都在一个项目内，然后在半年和一年之后业务发展起来了急需对现在的架构进行重构（说的不好听就是推翻重来了），原因如下：

1. 超过5人在同一个大项目中修改代码，分支管理代码冲突解决成本太高了。
2. 随着压力的上升这么简单的直肠子架构很难去拆分分散压力从而顶不住高并发。
3. 虽然对于MVC我们会有明确的目录来存放三大组件的逻辑但是随着业务逻辑越来越复杂，我们会有聚合的Controller和聚合的Service产生，所有组件不再位于同一个水平面，代码全都堆积在一起腐化很快，容易形成复制粘贴的趋向。

除非已经明确是实验性临时性的项目，我个人不建议以这样的方式起步，使用一个相对简单的架构（见文2）并不会浪费太多的时间，但是这个开局往往可以避免之后的推翻重来。

我个人从.NET转到Java平台，之前的公司有使用过PHP，Python，Go。经历过.NET和PHP转Java，经历过混用各种语言的公司。在这几想说几点：

1. 曾经犯过错，在团队不大的时候允许保留两种技术PHP和Java同时发展。无论大小，每个团队的成员都需要自己的技术发展和晋升，每个技术栈都有不同的运维方式，每个技术都会有各自的妖怪问题，在一个规模不大的技术团队里同时使用多个技术，对于团队来说真是一个很大的消耗。语言的确有各司其职发挥所长之说，但是小于30人规模的开发团队真没必要这么早进行技术栈的分叉。
2. 随着团队规模的扩大，处于招聘成本、使用成本、性能、资源丰富性等等问题，往往会进行技术转型，许多平台花了几年时间都无法彻底从.NET或PHP转到Java，这是一个痛苦的过程。虽说技术负责人总是趋向于一开始使用自己熟悉的技术栈来搭建系统，但是不得不承认Java这门综合性很强的语言是一个不错的开局方式，开源资源丰富、好招人、高手多、开发效率还凑活、性能也不算差、少点折腾就能把精力更多放到业务上。倒不是说.NET和PHP不好，而是我们最后需要接受很多残酷的现实。
3. 随着项目规模的扩大，很多东西势必需要自己来写，开源往往不适合，这个时候发挥语言各自的所长又会显得很重要。Go在性能方面、可移植性方面、开发效率方面、高并发友好性方面有独特的优势，是开发（网络）中间件的很不错的候选语言，往往可以替代C。Python的开发效率奇高，丰富的类库基本任何需求都是一行代码一句API解决问题，作为运维平台各种工具和爬虫的开发语言再适合不过，在AI方面也是鹤立鸡群无可替代。
4. 开发应该多接触几门语言，这是非常有好处的。有些语言在高并发方面有优势，有些语言在函数式编程方面发展的很好，有些语言在语法糖方面设计的很漂亮，每个语言在其特色上所在的层次会比较高一点，也容易被其它语言借鉴，多看一些语言会让自己知道每一个技术能好到什么程度，不容易在综合性语言中成为井底之蛙。

技术团队到了一定程度不但会横向拆分为前中后台，还会纵向拆分为框架架构团队和业务团队，研发中间件或框架的平台架构团队和一心耕耘业务代码的业务团队我都待过。在架构团队的时候我们总会吐槽：

1. 业务团队不愿意配合架构团队做技术升级，架构团队辛辛苦苦搞这些还不是在解决业务团队的问题？
2. 业务团队太谨慎保守了总是担心架构升级影响现有系统，想法太老旧了一点架构意识都没有？

在业务团队的时候我们又会吐槽：

1. 架构团队总是高高在上的样子，他们体会不到业务的复杂性，做出来的东西根本不实用，这么难用的东西还不如我们的土办法。
2. 架构团队的人是不是很轻松，业务团队天天加班搞项目，架构团队貌似都是在喝茶聊天研究一些不实用的东西。

在这里想表达几个观点：

1. 技术发展到一定的程度，一定是需要一些中间件或框架来做统一的事情，这些中间件结合在一起形成一个平台（见文5）可以大大减少出问题排错的时间，也可以让一些高并发下的优化工作更简单。
2. 架构团队的架构师最好是在业务团队深耕过，知道痛点所在的，这样研发出来的系统和工具能够和公司目前的项目所匹配发挥最大的作用，让大家爱不释手。
3. 在做架构升级的时候对业务侵入性越小越好，业务团队无感知最好，前提是我们的一些核心架构框架和中间件已经是统一的标准化的，有一些框架还是自己研发比较好，在之后的一些文中会提到这个观点。
4. 做业务往往变动大，我们总是会习惯很多事情先手动来做，慢慢形成了对工具化自动化理念没有这么敏锐。如果在这个时候有局外人能参与一下说不定可以碰撞出很多好的框架和工具来帮助我们提高生产力，这其实是一个好事情。

朱晔的互联网架构实践心得S1E1：Pilot

标签：修改   项目   现在   超过   负责人   案例   bsp   很多   中间   

原文地址：https://www.cnblogs.com/lovecindywang/p/9613195.html