一样简单3月26日，集训营邀请了滴滴出行资深架构师李凌辉与大家分享《架构设计之大道至简》。他主要和大家聊了聊他眼中的架构师之路和技巧，以及滴滴出行经历的一些酸甜苦辣和宝贵经验。嘉宾介绍滴滴出行首席架构师李凌辉李凌辉滴滴出行首席架构师，移动互联网资深从业者，对移动互联网技术发展趋势和技术团队组建有着独到的见解。多年互联网架构设计经验，擅长高性能、高并发、高可用的架构设计。曾主导滴滴打车技术迭代中核心服务架构的升级。建筑师的道与艺李令辉认为，建筑师行业有道有艺，艺术自然源于对道的理解。作为架构师，每次面对一个设计或者一个问题，都会有很多选择。这些选择都是技术上的选择，比如是用Java还是PHP来实现，用什么框架等等。其实这些细节真的没有那么重要。架构师真的需要做出选择，就是如何让整个东西的实现越来越复杂，或者越来越简单。作为一名架构师，他最重要的工作就是让事情的实现变得更容易、更简单。如果你有从大到小的思维方式，你对很多事情的看法都会改变。你会发现它们有共同的特点，一类问题可以通过一种方法来解决。把一件事情简单化是非常有价值的。简单意味着其他人很容易理解。你不容易忘记它，甚至忘记它。重新学习并不难。改革很容易。看透一切问题。做建筑，什么是建筑？建筑本身就是为了满足我们人类的需要。人的大脑并没有想象的那么好。我们只能面对一个比较简单单一的问题。架构的特点就是让我们每个弱势群体在处理问题的时候总是面对一个或者几个简单的问题，而不是很复杂的问题，也就是分而治之，降低管理的复杂性。架构有什么用？组织结构设计软件系统，架构为组织结构服务。这听起来有点奇怪，但事实是，有什么样的组织架构，就会设计什么样的软件系统。你会发现，如果两个人分属两个团队，同时在开发一个系统，时间久了，自然而然会拆分成两个系统，A系统和B系统，或者A模块和B模块依赖。你会发现在BAT这样的大公司里，各个团队和团队之间的接口是相当清晰的。很少有团队会说一件事情大家都负责，我提交的时候通知你，你的团队不要碰我团队的代码。所以说如果你想让一个系统越来越有凝聚力，那么你把维护系统的人放在一个团队中，让他们向一个老板汇报，让他们的KPI目标保持一致，因为这将与你的最终目标一致.当然，如果你想让他们把这两件事情当成两件相对独立的事情来做，好处是一部分人可以专注于一件事情，另一部分人可以专注于另一件事情，那你就把他们拆分成两件事情。团队，你不需要在架构方面做太多。所以架构设计是为组织架构服务的，如果你想让你的组织架构朝着你想要发展的方向发展。你应该让你设计的软件架构和你的组织结构尽可能与你未来想要的组织结构保持一致。建筑师做什么的？严格来说，建筑师的职业不仅仅是知识。你必须经历许多陷阱，你必须看到许多组织，你必须在非常复杂的系统上工作，最重要的是失败。经验然后对应于解决方案，尤其是他们之间纠结的经验。只有这样，你才能知道在实际生产环境和开发环境之间如何选择。架构师的首要职责是解决问题。你必须解决所有的技术问题。二是提高效率。面对快速迭代、快速变化的市场，如何紧跟发展趋势，低成本满足用户需求，是一个大问题。在工作中，懂得如何提高研发效率，提高组织架构效率，提高产品迭代速度，将是你战胜竞争对手的核心竞争力。第三是架构师必须不断响应变化。因为市场在变，组织和业务形态在变，用户的需求在变，所以架构师要不断的跟随着这个产品的发展，思考我们下一步应该往哪个方向走，我们的团队怎么组织，怎么去组织软件结构等2014年两大挑战及解决方案以下是李令辉分享的两个实际案例，是滴滴在2014年面临的两大挑战。第一个挑战是0级服务。这项服务非常重要。如果失败，整个滴滴将停止服务。不管你是司机还是乘客，你的APP都不行。第二个挑战，滴滴一上线，就是一个关系到生活、关系到国计民生的应用。从一开始就帮助大家省钱，为大家创造财富。所以，它从一开始就是一个带钱的应用，对于大多数互联网人来说是一个比较陌生的领域。0级服务面临的第一个问题是没有安全测试和集成测试，全靠用户操作测试。第二个问题是性能特别差。第三个问题是没有人维护现有的代码。更可怕的是，它使用了很多现在不太常见的奇怪技术，比如Apache。作为解决问题的架构师，我不喜欢只解决一个问题，而是希望解决某一类问题。考虑的核心诉求是什么？一是***不挂，二是要能干活。所以当MySQL被阻塞了，或者什么都被阻塞了，程序就不会再请求它了，直接返回一个值，因为程序的大部分请求是不依赖于存储的。另一个烦人的是它依赖于源B的存储。这个存储既不是开源的也不是内部开发的。这种存储不是很可控，经常在网络波动的时候出现写入失败。往往同一次写入，ABC写入三次，A失败，B成功，C再次失败。***读出的数值随机且可怕。接下来我们就来看看滴滴是如何解决写入失败的问题的。他们保持无国籍状态。这是如何实现的？当用户登录时，程序将时间窗口、手机号和一个key（这个key是根据你的手机号找到的唯一key）一起取下来，签上名字，然后计算出一个验证码发送对用户来说，只要用户在一分钟内返回验证码，程序就可以让用户登录，不需要依赖任何存储。后来说这样不行，用户可能不会那么快重新登录。解决方法是让用户尝试过去五分钟的验证码，如果任何一个成功，用户就可以登录。以上调整后的记录如何？第一，QPS到9000就没有感觉了。到了10000的时候，延迟略有改善，从平均延迟不到5毫秒，到10毫秒左右，其实也没什么大不了的。因为100毫秒也是可以接受的。然后就是部署，部署就变得很容易了，一个二进制，就是一个镜像，然后加个配置文件就可以上线了。可用性为100%。99%的请求不依赖于任何存储，通过网络实现日志收集。这是李令辉给大家分享的第一个案例，滴滴是如何解决遇到的问题，取得了什么样的成果。下面说一下在实现过程中需要注意的细节。首先，***必须定下一个疯狂的目标，给大家一些士气和动力。团队管理者在制定目标时一定不要制定长期目标，因为人的士气会全力以赴，然后衰退，三次就会疲惫不堪。二是不要太相信大团队。做任何惊喜的事情，最好有两三个人。如果这个数字超过这个数字，效率肯定很低。第三，不要盲目相信一些权威观点。其实那些专家不是你，也没那么值得信任。你可以向他们学习，听取他们的意见，但盲目照搬他们没有任何意义，因为只有你自己了解你的团队，你自己的能力，你面临的问题只有你自己清楚。再者，在一些合适的环境下，动态语言的优势并不是那么明显。一门灵活性相对较低、约束条件较强的工程语言会给你更多的帮助。虽然程序员的个体效率可能会下降，但团队的整体效率会得到显着提升。接下来说说滴滴支付面临的第二个问题。滴滴的支付系统有两套代码，两个系统。让我们谈谈它有什么问题。第一个问题是有多套代码。多套代码有什么问题？***的问题是哪里出了问题，工程师也不知道哪里出了问题。二是工程师解决了一个问题，不知道是不是全部解决了。三是工程师的测试量要翻倍，翻倍以上。第四，肯定是两套代码其中一套有问题，甚至两套都有问题。第二个问题与业务有关。初期，滴滴并没有专心致力发展支付的人，因为刚推出时，它只是一个没有支付的网约车平台，用户可以用现金支付。但是后来把支付开发成一个普通的应用，就出现了很大的问题。作为工程师，您不会将其视为一个单独的系统。这本身不是问题。问题是因为是一个人或者一群人开发的，当它需要改一个功能的时候，不是按照系统的边界来划分的，而是如何省事。比如给这些用户一个补贴，或者超额补贴，正常情况下，你不应该在支付系统里做，为什么呢？因为支付系统是为了收款和支付。这个地方改的越少越好，因为不能出错，但是你想，这么多代码，你怎么知道收敛点在哪里？大家会换成公共出入口，就是支付模块，因为所有的订单都会Flow到这里。运行一段时间后，你会发现支付系统在原来的系统中是非常冗余和庞大的，所有的功能都耦合在里面，甚至还有免账单的逻辑。你认为这个问题是工程师的问题吗？不，从工程师的角度来看，任务很多，他总会选择最快的方式，用最好的方式解决。都是软件工程学的吧。因此，工程师在这里进行了修改，很快就会生效。他觉得很安全，不过隔了半天，看看支付码？你会发现这不是支付系统！各种逻辑，还要判断车型，判断人，判断他有没有优惠券，什么时候发优惠券，有没有免费订单，各种逻辑，就是面条形码。更可怕的是，在添加新功能或者多余的判断的时候，你甚至都不知道该往哪里添加，更不知道该删掉哪些，因为它们看起来很有用。为什么是这样？这是因为您的组织结构的边界没有明确定义。第三个问题是支付比其他逻辑需要更多的一致性。解决方案是架构师需要了解事务隔离的级别并增加他们对一致性的理解。第四个问题是可扩展性很差。日常代码的实现需要能够捕获异常和处理事务。第五个问题是系统性问题，依赖单数据库事务。后来滴滴去掉了单库事务，不再依赖事务。***我不会说任何关于性能差和脏代码的事情。这是互联网上由来已久的问题。滴滴的支付团队是如何尝试解决上述问题的？***，他们做了最重要的事情，将项目命名为Phoenix。因为滴滴要涅槃重生，因为如果不重生，可能会烧坏。他们必须重生，所以项目名称是凤凰。他们设定了Phoenix的行为。互联网公司讲究速度，凡事要快。其实想清楚比部署快更重要，因为他们经常发现想清楚是没有必要的，想快比做快更重要。.正确的沟通组织架构不是简单的技术问题，而是应该遵循的。因此，他们当时抽象出一套支付原语。什么是支付原语？李令辉设计了一个类似MySQL的协议，没有那么复杂。云服务PASS时代，合作方为您提供一整套解决方案，您调用对方接口即可。后一套东西太复杂了，不值得滴滴去做。二是独立团队。李令辉当时意识到，组织架构决定了变现方式，所以他们用独立的团队来做支付，没有和原来的业务团队混在一起。第三，使用Java进行开发。为什么要使用新语言？PHP确实招不到合适靠谱的人。当时滴滴还没有和快的合并，主要是基于PHP架构，但是***这个服务是用Java做的，因为Java在支付领域已经是非常成熟的实践了，全球最大的支付，包括支付宝还有京东、银联的网银，包括PayPal，都是用Java开发的，Java可以解决这个问题。然后，支付团队孵化，保证团队之间的隔离，再去营业，这是他们的前提。通过几次变革和努力，滴滴实现了用很少的机器，实际上不到十台，来支持整个公司的业务。二是全年无停机，无主动事故。排除外部系统，不包括微信支付和支付宝挂机。三是不停机，不发生事故。事故与停机时间不同。滴滴单台宕机，但不影响服务。第四，没有回滚。这个非常重要。2015年，他们没有回滚线上代码的任何问题。五是接入滴滴所有产品线。了解更多训练营内容：http://x.51cto.com
