下载掌阅APP，畅读海量书库
立即打开
当今互联网应用呈现出高速发展的趋势。
（1）互联网理财用户规模持续扩大。越来越多的网民选择在网上购买理财产品。
（2）全国网络零售交易再创新高。2018年“双11”当天，全国网络零售交易额突破3000亿元，其中天猫全天成交额为2135亿元。
（3）移动支付使用率持续增长。无论是网上购物，还是实体店购物，大多数用户都选择微信或支付宝等移动支付软件。
（4）短视频应用“异军突起”。大多数网民都使用过短视频应用（如快手、抖音等），以满足碎片化的娱乐需求。
（5）在线政务应用发展迅速。支付宝和微信均提供了城市服务平台，以对接政务服务。政府也积极出台相关政策，推动政务线上化发展。
还有很多其他互联网应用，也都深刻影响了人们的出行、饮食、健康等方面。人们已经无法适应没有智能手机的时代了。这些大型互联网应用大多都具有以下特征。
“快”是所有互联网公司产品的特征。互联网公司要生存，就必须要与时间赛跑，与同行竞速。可以说，哪家公司能够率先推出产品，就能在同类市场上掌握极大的主动权。
推出产品，非常重要的一环就是产品的开发。只有更快地开发出产品，才能更快地推出产品。
正如上面所说，“快”是所有互联网公司的诉求。那么如何才能实现快速开发呢？业界比较推崇的开发模式是渐进式开发。
所谓“渐进式”，是相对于传统的“瀑布模型”而言的。瀑布模型是一种软件开发方式，其开发过程是通过设计一系列阶段顺序展开的。从系统需求分析到产品发布和维护，每个阶段都会循环反馈。因此，如果有信息未被覆盖或发现了问题，那么可以返回上一个阶段并进行适当的修改。
瀑布模型有一个非常致命的弱点，就是会拉长整个产品推出的周期。毕竟如果每个阶段都考虑得非常全面的话，那么整个项目在最后的时间节点才能推出产品，这个时间点离最初的立项时间有可能间隔了数年。且不论开发、测试过程中可能会发现问题，导致“回滚”到上一个阶段，谁又能保证一款开发时间达数年之久的产品，最终还能够被用户所接受呢？用户在这么长的时间内想法不会产生变化吗？市场不会产生变化吗？
因为无法预料变化，所以应对变化的最好方式就是缩短周期。不去想若干年后的需求，把一个长期的大需求分解为若干个短期的小需求，即只考虑近几个月或近几个星期的需求。针对短期需求进行设计，而后开发，这就是所谓的“渐进式开发”方式。
渐进式开发方式能够及时感知需求产生的变化，从而调整开发策略。
互联网公司的产品是不断变化的，唯一一成不变的产品，就是那些已经被市场淘汰了的。所以，如果一款产品还在不断地推出更新包，起码从侧面反映出该产品仍然在积极地做调整，同时也证明了该产品的需求量及开发的活跃度都比较高。
因此，只有拥抱变化的产品，才能够及时满足用户的需求。
用户的需求有时是明确的，但有时也是不明确的。只有在用户真正使用了产品之后，才能进一步完善需求。所以很多时候，变更需求都是在用户使用产品的过程中提出的。
互联网公司大多采用敏捷开发方式。敏捷开发与渐进式开发有异曲同工之妙。
敏捷开发是将产品的开发周期划分为若干个“迭代”。一般一个迭代为4周或2周。开发团队全力完成当前迭代所确定的目标。在迭代完成之后，会发布一个可用的版本，交付给用户使用。
敏捷开发方式保障了产品能够及时交付给用户，同时也保障了开发团队能够及时从用户那里获取产品的使用反馈。这些反馈有可能是正面的，也可能是负面的。开发团队对用户反馈的内容进行整理，并将其纳入到下一个迭代的开发中去。
这样，开发团队与用户之间就形成了正向的闭环，可以使产品越来越趋近于用户的真实需求。
开源技术相对于闭源技术而言，有其优势：一方面，开源技术源码是公开的，互联网公司在考察某项技术是否符合自身开发需求时，可以对源码进行分析；另一方面，开源技术商所花费的成本相对较低，这对于很多初创的互联网公司而言，可以节省一大笔技术投入。
当然，开源技术是把双刃剑，能够看到源码，并不意味着可以解决所有问题。开源技术在技术支持上不能与闭源技术相提并论，毕竟闭源技术有成熟的商业模式，可以提供足够的商业支持，而开源技术更多的是依赖于开源社区的支持。如果在使用开源技术的过程中发现了问题，可以反馈给开源社区，但开源社区不能保证什么时候、什么版本能够修复发现的问题。所以，使用开源技术，需要开发团队对其要有足够的了解。最好能够“吃透”源码，这样在发现源码中的问题时，能够及时解决。
例如，在关系型数据库方面，同属于Oracle公司的MySQL数据库和Oracle数据库，就是开源与闭源技术的两大代表，两者占据了全球数据库使用率的前两名
。MySQL数据库主要是被中小企业和云计算供应商广泛采用，而Oracle数据库则由于其稳定、高性能的特性，深受政府和银行等客户的信赖。图1-1所示为2019年2月的数据库排名。
图1-1 数据库排名
相比敏捷开发方式将开发周期划分为若干个开发阶段，微服务架构则侧重于把整个软件划分为若干个不可分割的“原子”服务，这类原子服务就是微服务。
微服务架构采用DDD（领域驱动设计）方式来进行业务建模，将每个微服务都设计成一个DDD边界上下文（Bounded Context）。这为系统内的微服务提供了一个逻辑边界，每个独立的团队负责一个逻辑上定义好的系统切片，负责与一个领域或业务功能相关的全部功能的开发，这样，团队开发出的最终代码会更易于理解和维护。
微服务架构可以理解为是SOA（面向服务的架构）的一种特殊形式。这些服务之间由定义良好的接口和契约进行连接。接口采用中立的、与平台无关的方式进行定义，所以其能够跨越不同的硬件平台、操作系统和编程语言。
如果读者想完整了解微服务架构的设计，可以参阅笔者所著的《Spring Cloud微服务架构开发实战》。
大型互联网应用往往有着非常高的并发量，如何抵御突如其来的流量洪峰，是每个运维人员需要思考的问题。其中一种常见的解决方案是，将经常需要访问的数据缓存起来，这样在下次查询的时候就能快速地找到这些数据。
缓存的使用与系统的时效性有着非常大的关系。当应用的时效性要求不高时，则选择使用缓存是极好的。当系统要求的时效性比较高时，则不适合使用缓存。
本书后续章节会以Redis缓存的应用为例做详细介绍。
大型互联网应用往往会设置服务集群，多实例部署的方式可以提高整个系统的可用性。本书后续章节会就高可用展开详细讨论，同时也会对NGINX负载均衡、反向代理技术进行介绍。