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