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

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

 

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

1. 各类废话的闲聊和吐槽
2. 屡试不爽的架构三马车：介绍一个简单实用的可扩展的互联网架构
3. 相辅相成的存储五件套：介绍一下我的比较喜欢的一个存储组合以及适用场景
4. 简单好用的监控六兄弟：介绍监控方面一直在用的一些工具以及强调监控的重要性
5. 不断耕耘的基础中间件：中后期的项目须要有完善的基础中间件，这里进行逐一介绍
6. 给飞机换引擎和安全意识十原则：分享一些对高速发展项目进行重构以及安全方面的一些经验
7. 三十种架构设计模式（上）：微软一些架构方面的设计模式
8. 三十种架构设计模式（下）：微软一些架构方面的设计模式
9. 架构评审一百问和设计文档五要素：架构评审考察点和如何写设计文档
10. 数据的权衡和折腾：以数据的维度谈谈架构设计中的权衡和复杂点

 

有关All-In-One架构

不少项目起步的时候都会以一个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. 作业务每每变更大，咱们老是会习惯不少事情先手动来作，慢慢造成了对工具化自动化理念没有这么敏锐。若是在这个时候有局外人能参与一下说不定能够碰撞出不少好的框架和工具来帮助咱们提升生产力，这实际上是一个好事情。