作者：网易云基础服务架构团队
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
云原生应用架构实践试读：
内容简介
针对企业如何采用云原生架构实现高效的产品迭代能力、支持互联网业务健康发展，本书总结了一套可行的方法论。书中详解了云原生应用的内涵和要点，对实现云原生应用面临的功能和非功能（高性能、高可用、可扩展、安全性、高可靠等）的不同阶段需求和实现方案进行了较为完整的梳理。内容涵盖了系统工程化、高性能数据库、分布式数据库、DevOps、微服务架构、服务化测试、多机房架构等方面，既有业务挑战分析，也有架构实践指导，并通过实战案例加以诠释。
本书适合希望采用云计算帮助企业实现业务提升的 CTO、CIO、架构师等群体。
前 言
从互联网、移动互联网到云计算、大数据、人工智能，再到虚拟现实/增强现实，十多年来，信息技术的日新月异催生了不断涌现的互联网新业态，也推动了传统行业投身于数字化创新的浪潮。此时此刻，机器取代人类的说法固然夸张，却也真实地反映了新技术应用对产业带来的冲击。
全球顶级商业机构都是能够把握技术创新成果的企业；而对技术运用不当的企业，即便起点与前者一致，或许也曾风光一时，但最终还是步履维艰，甚至烟消云散。决定能否与技术趋势同行的一个核心因素就是技术架构。如果说商业模式是商业组织的灵魂，那么架构就是灵魂的根基。最典型的例子就是电商618、双11大促，流量爆发之下如何保障整个商品交易流程的体验，对系统设计和运维保障都是巨大的考验，这也推动了技术的进步。当前的大促活动依然让电商企业如履如临，然而挑战难度已经不如七八年前，这就是架构演进趋于成熟的表现，充分利用云计算理念的“互联网架构”由此为业界所推崇。
综合考虑 IT资产、业务规模、发展阶段、人才储备及投资成本，不同企业需要的互联网架构并不完全一样，譬如初创公司考虑百万级并发可能不合时宜，然而为长远计，想跟上发展迅速、爆发力惊人的互联网业务，架构设计需要既能满足当前业务需求，又具备快速升级支撑下一个发展阶段的能力。企业如何正确驾驭架构的设计和演进？有哪些通用的成熟经验可供借鉴？业界对此不乏零星的讨论，但企业仍缺乏系统的、可指导实践的参考资料。
本书是网易云基础服务架构团队根据网易集团的十余年实践，结合社区优秀案例总结而成的互联网架构演进指南。2006年，怀着储备互联网技术和孵化新业务的初衷，网易杭州研究院扬帆起航，及至今日在两个方向上都有不俗的成绩，一端是分布式、云计算、大数据、人工智能、增强现实，一端是教育、电商、金融、游戏，这一切都是构建在千锤百炼的互联网架构之上的，这就是同时满足功能性需求、非功能性需求和产品快速迭代需求的云原生架构。网易云希望把这些经验分享给业界，与各行各业一起践行中国云计算。
全书共5章，以商业组织的互联网业务成长为主线，着眼于业务需求，清晰地剖析互联网架构的挑战，云原生架构的特征、构成和解决的问题，以及架构演进的路径，并通过案例对设计原则和实践加以诠释。通过阅读本书，架构师能够借鉴网易十余年的经验结晶，无须反复试验，即可快速设计符合互联网业务场景需求的架构，而有一定基础的读者朋友也能更加透彻地理解和规划未来的方向。
全书由尧飘海统筹构思，网易云基础服务架构团队成员参与写作，书中部分图片脱胎于社区文档或官方宣传资料。第1章以宏观视角简明地解析互联网业务挑战及架构演进要点；第2章介绍开始搭建业务系统时需要的项目版本管理工具、以Docker为代表的容器技术，以及常见语言的工程化构建方式，并结合实战示例给予完整展现；第3章针对访问流量不是很大的业务起步阶段，讲述如何做好技术选型，实现一个支持快速迭代、高可用、安全的应用服务端；第4章介绍如何解决业务高速成长阶段的可扩展性、性能、系统集成与交互、数据可靠性等挑战；第5章以分布式定时任务和分布式锁系统的实现为例，介绍分布式服务应用挑战和架构方法，重点解析了微服务架构、分布式数据一致性和同城多活的实践。
全书内容分别由尧飘海、焦智慧、王新勇、张小刚和冯常健主笔，黄庆兵、郭忆、乔安然、何李夫、孙建良、刘发明、沈明星、崔晓晴、易庭、祝剑锋、姜政冬、朱凌墨等网易云架构师和工程师参与了写作，插图由李倩倩和纪桂莲支持完成。
本书的付梓要特别感谢电子工业出版社的符隆美编辑，她帮助我们及时地解决了遇到的各种问题。
限于作者的精力与能力，书中难免出现一些疏漏之处，请广大读者不吝指正，并予以包涵，我们会在再版中修正。
推荐序一
不知不觉，网易公司已经走到第20个年头。网易的业务从邮箱、门户和游戏业务，拓展到电商、文娱、教育和农业板块，并在云计算、大数据、人工智能、增强现实等领域进行了战略布局。每一项业务的健康发展，从“道”的层面而言是在于与用户共同成长，从“术”的层面则是不断打磨产品，使之更好地满足用户需求。
互联网信奉“快”，但网易更尊重“匠心”，产品每一个特性的更新，都需要经过反复的验证。这也意味着，网易业务多元化背后需要大量的产品研发和迭代工作，因此，与之匹配的应用架构至关重要。网易架构在业务成长中不断演进，形成了当下的云原生架构，让95%的互联网业务真正运行于云端，业务团队只需要努力为业务编码。由此，“快”和“匠心”在产品端得到了平衡。我相信，云原生是互联网业务的最优解。
云原生与传统云计算最大的区别在于，传统云计算关注的是如何提供性价比最高的计算、存储、网络资源，而云原生关注的是如何让产品能够支持快速验证业务模式，如何简化复杂的开发流程、提升研发效率，如何保障产品的高可用性让业务无需承受成长之痛，如何实现大规模弹性伸缩轻松应对业务爆发，等等。也正因如此，“云原生架构”虽然只有短短的五个字，其落地却隐藏了无数的变量与陷阱。
介于此，本书系统梳理了网易云原生架构的演进经验，对不同的挑战分别给出相应答案。网易架构仍在演进，我不能说这些答案已经很成熟，但我相信，书中一定会有一些章节正好击中不同企业的痛点，帮助企业在互联网业务创新过程中少走一些弯路。网易希望借此与大家共同交流探讨。陈 刚网易杭州研究院院长
推荐序二
作为一家诞生于中国互联网萌芽期的互联网公司，网易具有丰富的产品线。长久在网易任职，一个很大的好处是能够真切地经历波澜壮阔的互联网发展史，而对于技术人来说，更重要的是能够学习和实践各项支撑互联网爆炸式发展的技术，能够在这段经历中获得不同于纸上得来的知识和思想：能切实体会到许多技术为何产生、为何沉寂或者兴起，从而能够在实践中避免因循守旧或一味求新逐异；更懂得如何根据功能、非功能性需求进行取舍，选择更有生命力的技术；更加理解架构的本质。
我和我的团队从十多年前的博客时代开始接触互联网技术，当时 Web2.0概念刚刚兴起，网易博客一上线，用户量、访问量就呈爆发式增长，我们最大的困难并不在于如何编写代码，而是怎样支持产品的高速迭代。以往我们并未经历业务几乎每天都在更新迭代的情况，此时通宵更新版本成了家常便饭，为此我们优化了版本控制策略，研发并集成了自动化构建和发布工具，将其总结为“项目工程化”，在之后的项目中尤为重视。
然而，当时博客业务也在变得日益复杂。更新版本时，团队间的协调成为拖慢迭代节奏的重要因素，因此我们开始把一些业务模块独立出来，以远程接口方式提供服务，或是在负载均衡入口直接按业务模块分流，后台的缓存、数据库也做了相应的拆分，服务化进程就这样自然地开始了，团队曾考虑借鉴当时业界流行的SOA（面向服务架构）理念，想引入企业服务总线等重量级设施，但由于 2C业务和性能意味着用户量的支持及实际的用户体验，基于对更轻量、更高性能的渴望，我们最终选择了类似微服务的架构形态。
服务化一旦开展，过程就变得更加复杂。随着发布的频度再次提升，服务单独升级带来了版本问题，以及维护、故障期间的雪崩等一系列棘手的问题，代码质量也开始下降，由于各种方式的RPC调用、服务发现封装方式大量地充斥在代码中，我们意识到必须要有统一的框架支持服务化进程，于是近十年前我们有了自己的微服务框架，逐步解决雪崩、版本、服务发现、降级等问题。
后博客时代，我们将工程化、服务化等工具、框架应用于新的业务，又发现了新的问题。服务化带来了业务计算节点种类和数量的大幅增长，运维部署变得非常困难，在资源层面，服务化后的节点无法充分利用服务器资源，众多的服务被混合部署在同一台服务器上，从而服务间资源争抢，故障恢复时与各产品、各模块的协调成了最麻烦的问题，我们意识到单台服务器的负载在短短几年内已发生了极大的改变，要解决资源管理问题，云计算势在必行。
很幸运的是我与团队能受公司之托来负责云计算平台的研发工作，2012年秋，网易云计算平台正式开始支持公司业务，得益于SDN技术与公司原内网环境的较好融合，云平台很快得到了广泛使用。相比物理机节点数量的线性增长，虚拟机的数量指数级增长在很大程度上解决了原本遇到的资源管理问题；虚拟主机做到专机专用按需配置，使用数据库、缓存等基础服务再也不用等待运维团队部署维护，系统运维效率也得到了极大的提升。
获取资源容易了，产品自然而然规划出众多的测试环境，如开发环境、集成环境、预发布环境等，于是搭建测试环境，持续集成与交付很快成了新瓶颈，更麻烦的是业务服务化架构日渐成型，应用运维的复杂度指数级提升。为此，我们又打造了自动化部署平台，解决集群的编排、版本更新、回滚等问题，平台上线后每月的部署次数直线上升，达到数万次之多。没有云计算时，我们觉得两套测试环境共用就行，每天集成部署一两次就行，有了云计算后，原本被压抑的资源、迭代频度的需求被瞬间释放，反应到产品中的便是功能开发并行度和迭代速度的大幅提升，迭代风险的大幅下降。上云的收益由此可见一斑，先行拥抱云计算的企业在产品竞争中可获得巨大的优势。
可以说在网易这样的成熟互联网公司，是原本的软件架构、技术体系的进化推动了云计算的实施，塑造了云计算平台的形态，我们的业务技术架构是与云计算伴随生长的，并且经历了漫长的迭代过程，而对于后来者，基于云来设计软件架构、实现工程化、建设运维体系，则可以选择一条前人已充分实践并总结和提炼的路径，一开始便可以从云而生，这也就是我们所说的云原生的技术体系。我们在开放网易云计算能力的过程中遇到过不少用户，他们不知道网易这样的互联网企业如何基于云高速迭代产品、支撑海量用户，不知道如何在架构设计、技术选型阶段迈出第一步，如何为未来的发展打下基础，或是业务增长后如何应对。有初创企业虽然灵活快速却控制不了迭代质量、刹不住车的，也有传统企业提不了速的。正是看到这些问题，我认为，作为互联网技术的实践者，我们不仅应当将我们的平台、工具链开放出来，同时也应将我们的云端架构实践梳理成知识体系分享出来，在这“大众创业，万众创新”的互联网+时代为企业健康发展作出力所能及的贡献。陈 谔网易杭州研究院云计算技术部总监
引子
Netscape创始人、硅谷著名投资人马克·安德森（Marc Andreessen）6年前在《华尔街日报》上发表了“软件正在吞噬整个世界”的论断。目前来看，这一论断得到了有力的证明，软件的发展趋势越来越强劲。当前世界，每时每刻都有软件在发布和更新。特别是随着移动互联网技术的发展和普及，软件也渐渐变成我们生活中的一部分，从而对我们的生活方式产生非常重大的影响。然而，如此大数量和大规模的软件开发依赖非常多的人力和时间去设计、开发、测试和发布，因此，如何在满足产品发布需求的情况下，保证软件高效的生命周期管理，需要考虑的因素非常复杂，大部分通过分层抽象，分解成一个个小问题来处理，云原生应用就为解决此类问题提供了一种有效的方法。
首先，由于产品快速迭代的需求，高效组织或个人一般会通过云原生服务来快速构建和交付可用性更高的应用，云原生应用由于天然基于云服务的开发模式，通常包括持续集成、DevOps和微服务架构等过程。毫无疑问，这些过程是相互融合、交织在一起的，只能通过自动化来提高整体的运行效率。所以成员之间相互信任、主动快速、良好的操作体验也可以在云原生应用中得到体现。
其次，软件系统一定会发生错误，云原生应用通过不同的服务来构建可靠的软件系统，因此为错误而进行架构设计必须提供自助式服务，服务架构的设计需要满足可伸缩性并具有容错性，软件的出错后行为应该是可预测的，应用通过自动恢复来保证业务的可用性。
最后，云原生应用使得用户把焦点更多关注在代码及架构本身，通过完全自动化模式来交付软件，以应用为中心，而不用关注后台是在和虚拟机还是容器或者其他基础设施打交道。因此，云原生应用设计时需要从特定的基础设施中进行解耦，不能与特定的平台绑定，依赖于团队的架构设计能力和协作约定，以工程化、服务化和自动化的流程来进行应用开发。
第1章互联网系统架构的挑战
21世纪初期，随着互联网接入逐渐普及，Web 2.0业务模式飞速发展，大量互联网或者企业应用系统所需要处理的数据量急速增长，如何在用户数量迅速增长的情况下快速扩展原有系统，是技术人员必须面对的问题。无论是在软件资源的时间维度上，还是在硬件资源的空间维度上，资源的有限性，比如交付周期、电力成本、空间成本和维护成本等，会直接导致数据中心成本上升，而另一方面资源的使用率又不高。因此，如何在满足业务快速增长需求的同时，有效地解决成本与效率的矛盾，是企业面临的一个重大问题。借鉴传统水电煤的商业发展模式，技术人员通过集中提供资源的方式，将计算、网络和存储等资源提供集中化统一管理，于是云计算应运而生。
从AWS CEO安迪·加西（Andy Jassy）于2003年提交的商业计划书，到2006年ECS（弹性云服务器）正式上线提供商业服务，再到2016年“AWS re:Invent 2016”大会的发展，云计算首先是在商业模式上带来了一个崭新的、获取计算资源的模式，以提供水电煤的方式来为用户提供资源，是一种对资源获取方式的变革，也是人类思维的基础和模式上的飞跃。因此，从这个意义上讲，云计算和传统主机业务相比有非常大的不同。比如，资源的使用由传统的准备订购模式变成了订阅的模式，也就是说业务需要多少资源，就可以从服务商那里购买多少资源，用户不需要过多关注资源的基础准备，这和普通的资源准备有很大的不同。同样，对资源的付费方式，也产生了多种灵活的模式，用多少就付多少费，用户可以对于固定的资源直接采用“包年包月”的方式，也可以按需付费，甚至可以做到在不同的时间段采取不同的收费模式，这和我们日常使用峰谷电的模式思路类似，都是为了实现资源利用率的最大化。另外，用户也无须在建设或租用机房、网络规划等方面投入大量的人力和硬件。
在“大众创业、万众创新”的政府政策和市场环境下，互联网化需求逐渐明显，伴随着互联网技术日新月异的发展和创业门槛的日益变低，从早期的独角兽到如今的大众创业，云化在国内外是个再普通不过的话题了。每个创业公司不再是讨论要不要上云，而是讨论如何上云及如何快速上云。同样，技术的发展也带来了对传统行业的冲击，移动互联网的飞速发展，智能手机的普及，每个人的碎片时间越来越多，造就了越来越多的机会，特别是大型互联网公司与传统企业的结合带动了更快的消费升级。
传统行业对互联网的转型需求也越来越大，很多大型传统国有企业、金融和银行业都在积极响应国家的号召，争取大部分业务上云。一方面是新型的创业公司根据业务发展不断调整系统架构，另一方面是传统行业的互联网转型将面临新业务的建立和遗留系统的集成。
在项目初期，云计算为用户带来的好处显而易见。首先，互联网项目前期资金投入在固定资产的比例越小，对产品开发或者创业来讲成本风险就越小，从而有更多资源放在业务上，云计算把计算资源从以前昂贵的预备方式变成一种使用较低的成本就唾手可得的方式；其次，使用云计算以前，计算资源的获取往往是一个比较漫长的过程，涉及选型、下单、生产、运输、初始化再到环境的搭建等多个环节，而现在变成了云计算公司的选择、数据中心的选择、云主机的选购，以及服务器的配置、安装、调试等过程。新的方式变成了一个简简单单的订购过程。如果是自己建设，除去各种政策的影响，仅机房的位置选择就是一个非常漫长的过程。而现在，很多情况下，只要在云计算公司的网站上像选择普通商品一样，加入购物车并支付，就可以马上获取所需资源，如果发生错误或者不需要了，可以立即销毁重做，不需要涉及复杂的下架回收流程。云计算缩短了很多产品的发布周期，这对于中小公司特别是刚刚起步的公司来说，大大提高了工作效率。
互联网的规模不仅越来越大，而且随着移动互联网的出现和飞速发展，热点随时随地可能产生。比如一些热销产品，一个热门事件就有可能导致系统流量的暴涨，特别是如今名人、大V等的宣传或转发，对系统的压力要求更大。比如之前的某明星离婚事件、某电子商务运营秒杀抢购业务等。
当然，正是由于初创公司不同业务的快速发展，才有机会使得互联网从业人员有更多的机会去挑战不同的技术难题，使用更好的技术以更好地服务用户。通常，很多业务型企业一开始都不太注重基础设施建设，也比较少有机会对系统进行良好的架构设计，随着企业的飞速发展，往往会碰到各种技术问题，可能会影响产品的迭代速度，容易错失很多机会，如果这时候对产品的核心架构进行调整，就像为高速行驶的汽车更换引擎一样，是一件很困难的事。诚然，这种比喻有点夸张，但是对于竞争激烈的企业来说，这种机会就显得非常重要，直接采用云服务的模式来打造，架构设计会更简单，同时还能提供更高的可用性保证，也不用非常大的基础投入，算是云服务给架构设计带来的一大优势。
因此，满足产品的快速迭代需求，保证系统既能满足功能性需求又能满足非功能性需求，是技术人员所追求的目标，也是技术的价值所在。1.1 云应用架构技术发展
随着云计算的发展和进化，以及企业对效率的追求变得越来越高，大量的数据表明，简单的云主机创建也不太能满足业务的需求，后续还有大量的运维和运营工作，运维操作频率基本占比在90%以上，尤其在业务本身不断发展并且规模不断扩大的时候会更加明显，矛盾也会越来越突出。所以，如何在速度与稳定性之间追求平衡，达到效率的最优化是本阶段用户追求的目标，因此我们迫切需要新一代的云计算技术出现，使得用户有更大的聚集业务，而不是烦琐的重复机械操作，在服务发现、编排和集成方面有完善的自动化工具集来帮助用户代替手工操作，帮助技术人员发现问题、解决问题、预测问题，甚至自动修复问题。
显然，商业模式和技术模式都在不断变化，互相促进，对开发者来讲，基于云计算的开发模式自然会导致思维的转变。当然不是说老的模式就不可以使用，而是说如果要更好地发挥云的特性，就需要在开发模式上进行最佳实践，尤其需要在架构设计上进行适当的调整。比如对使用资源的考虑，必须从单一服务器的资源，逐渐向整个资源池或数据中心的方向转变，架构也需要从单体的架构向服务化的架构转变。相应地，在架构设计的时候，面向的是整体资源的需求及运用，而不是在设计架构时局限于某一台物理服务器，因为所有的服务都有可能失败，也是不可靠的，错误也无法避免，如果以服务器为单位来进行架构设计就变得不适合了，这是一个比较大的变化；另外，从自建模式变成租用模式，很多人会对安全性有顾虑，认为自建更可靠，实际上这是个伪命题，类似认为把钱放在自家比放在银行更保险一样，实际上无论放在哪里都可能发生问题，因此，要根据用户的数据本身对安全风险的承受度，来重新考虑数据的安全问题。如果想降低风险，可以把数据做更细小的划分，划分的数据如何分别存储和调度，是需要设计的。因此需要开发模式的变化，把云计算的基础设施当成代码去使用，融合到设计中去。
作为基础架构的提供商，老一代云计算的服务提供商像水电力公司，新一代的云计算服务商更像现代化的工厂。互联网业务的发展和工业的发展是相辅相成的，比如工业 4.0的理念与实践，目的之一是实现工业从集中式向分布式的方向发展，和架构演变模式完全一致。
简而言之，用户最需要云服务实现以下3点基本特性，第一是可用性，服务商随时保证对服务的可使用性，就像在家需要随时能够打开电源开关，随时能够取用水资源；第二是可扩展性，也叫弹性，服务商能够随时满足业务在爆发时的需求，就像家里有朋友集会时，我可能需要更多的水，更多的电源，基础服务公司需要去负责这些资源的调度，而用户不需要去做其他改变；第三是可管理性，用户能够随时对基础设施提供的服务进行管理，自动控制服务，就像装修时布线、开关和插座等的设计，需要能够满足不同房间的各种不同需求，比如书房和儿童房的需求是有区别的。
对于云计算服务商而言，这3点都是必不可少的要素，是必要条件，只有满足了这3个条件，才能够满足最终用户的基本需求。所以为了提供更多的优质服务，需要新的云计算服务，需要IaaS服务和PaaS服务最终融合在一起，提供更流畅的、一致的生态体验服务。无论提供怎样的方式、提供何种类型的服务，对于最终用户来说，是追求效率的提高和资源的最大化利用。总之，用户对于云计算服务使用要求的多样性，要远远比任何一种以前的传统服务多得多，基础设施的可编程性和服务的 API，对于云计算厂商来说都是非常重要的。
云计算技术的发展刚好见证了互联网技术的发展，从物理机、虚拟机到容器技术的使用，从传统的瀑布开发到敏捷流程再到精益迭代，互联网技术对开发者的要求也会越来越多样化，甚至包括多地理位置的多样协作等，为开发者带来更多的问题同时，也会带来许多有意思的技术内容，既是机遇也是挑战。1.2 云平台下架构的不同点
毫无疑问，现在是云计算时代，前文也阐述了云计算不仅是一种IT资源的使用方式，而且已经演变成一种生态，它不仅会对软件开发人员的开发流程带来一定改变，更重要的是会为软件架构设计带来深刻影响。二者相互结合，也将导致对整个产品的上线和迭代速度产生连锁反应，比如云计算使得开发者无须再关注硬件资源，使得交付流程更快。然而，又可能由于依赖云服务厂商的技术稳定性不一样，所以在架构设计的时候要更多考虑到云的特性来满足非功能需求。2013年微服务的呈现到现在非常火热的场景刚好和云计算的发展一致，有些人甚至认为它就是云服务时代的产物。如何基于“云”做软件架构设计，或者如何让自己原来的软件架构能迁移到“云”上，本书给出了原理和初步的方法，相信能给读者带来一些启示，我们先来总结一下云计算对技术人员的影响。1.2.1 开发模式的区别
开发人员和测试人员之间
传统的开发人员在本地开发或测试完成之后，还需要重新上传到服务器端进行环境的安装、搭建和调试，在最后上线时又要重新做一次之前的工作，整个流程不仅烦琐，而且容易出错；除此之外，测试人员也会对测试的内容质量没有完全的把握，因此不能完全保证所有的运行环境完全一致，容易产生沟通矛盾等问题。
开发人员和运维人员之间
一般来说，产品经过开发测试之后，常常会分发到各阶段流程中，即产品上线。上线的流程通常包括资源申请、系统安装、环境配置等，有些可能包括容量规划、资源申请与审批、工单申请和反复沟通等，即使是在使用虚拟机的阶段，也需要有一个过程。根据权威的调查报告，一般虚拟机的创建时间最长不超过15分钟，然而业务上线却要长达2到3周，整个流程非常缓慢。
图 1-1中，基于物理的开发流程要经过业务需求、采购审批、安装机器、软件安装到应用部署5个步骤，基于虚拟机的开发流程只要经过业务需求、软件安装和应用部署3个步骤，相对来说流程有几步优化。但是实际上由于软件安排、升级的依赖性，团队仍然需要大量的时间去做基础的重复劳动，效率提升不明显。基于以应用为中心的模式只需要从业务需求到应用部署2个步骤，把第二种开发流程中烦琐的软件安装通过自动化的模式来完成，保证了软件环境一致性，减少了系统依赖的风险，同时开发人员只要聚集在应用上，其他由基础设施服务一键完成，大大提高了软件的生产效率。图1-1 3种软件开发流程比较1.2.2 交付模式的区别
开发人员或者架构人员在完成应用的开发测试后，还要编写对应的文档来和运维人员描述系统的部署架构，但是开发人员和运维人员对技术的理解存在不一致，同时对业务的理解也不一样。我们不可能让运维人员重新学习相关的业务知识，让他们完整理解整个业务的架构又相当困难，毕竟运维人员不像开发人员一样能理解整个产品的需求和开发过程，而且他们同时还可能兼任各个产品的运维任务，没有那么多精力来完全了解整个业务架构。因此整个发布流程是中断、有隔离的，并不流畅，如图1-2所示。图1-2 软件发布流程
除此之外，无论大小公司，还存在运维人员人力招聘、成本预算等问题，由于这个问题和本书的主题关系不大，对应的背景和上下文在此就不再详述。总之，无论在创业型的互联网企业，还是在传统的互联网+企业，甚至是大型的互联网企业，都希望能够进行比较流畅的开发测试上线的流程体验。最后，从开发到测试再到上线及监控反馈，整个过程应该能够不断反馈和螺旋上升，如图1-3所示。因此，为了解决相关的问题，除了流程、组织、工具等需要培养之外，既需要技术人员在实现软件开发和交付模式的转变，也更需要在技术上关注架构的调整来满足软件的架构需求作保证。图1-3 预期的软件迭代流程1.2.3 架构设计的区别
云应用架构设计意味着更快的迭代速度、持续可用的服务、弹性扩容及一些非功能需求，包括追求产品创新时间的技术挑战、以用户体验为中心的挑战和移动互联网时代的突发性挑战。
更快的迭代速度
无论是个人还是企业，抓住更多的商业机会、更加快速地交付软件是整个组织追求的目标，软件开发人员也在更加快速地迭代持续交付软件，因此，除了提高软件的开发效率，软件的整个生命周期效率的提高也是追求的一部分。
持续可用的服务
在互联网及互联网+的业务中，除了满足业务的基本功能性需求以外，对于需要持续提供服务的业务，系统架构的设计还必须满足非功能性需求，如何保证业务永远在线是架构设计的第一要素，因此，实现业务的24小时持续可用（即高可用）也是云应用的特点之一。
弹性伸缩
病毒效应在互联网场景下非常明显，因此，能够根据业务的流量和系统压力进行智能的弹性计算，也是云应用的显著特点之一，特别是在面对流量爆发或者突发事情的情况，还能保证业务的可用性，因此，业务设计的时候是否能够分析出业务的关键路径和热点部件，同时在架构层面保持足够的灵活性，以满足业务的弹性要求，并在低压力的情况下，保证资源的占用自动缩容，以减轻业务部门的成本支出；对于非核心的业务，启用避开峰值的方式来实现在线或离线业务的计算，尽可能实现云计算最大利用率，也就是常说的用好“云”，发挥云计算的最大价值。
非功能需求
随着技术的发展，很多创新型公司的发展速度也越来越快，很多企业能够在较短的时间内达到独角兽的角色，甚至有些公司能够在一年之内就到达上千万用户量的规模。在业务急速发展的过程中，对技术的架构将会形成极大的挑战，如果从一开始没有很好的技术架构支撑，将导致后续的技术债越来越重，严重影响业务发展。除了业务对技术的影响外，技术也会对业务带来影响，两者相辅相成。这类创业公司常常具有很多共同的特征，例如追求产品创新和极致的用户体验，主要包括以下几部分。
· 云模式的产品创新
现在每年有非常多的企业诞生，很多企业都希望把传统行业和互联网结合来追求新的商业模式，所以在不停地进行产品研究和创新，对此类企业而言，时间是一个非常重要的因素。此外，产品上的改变也越来越多地依赖“云”上的技术来完成，比如人工智能、数据推荐等技术，这些产品的创新必须依赖云计算的技术才能完成。
· 以用户体验为中心
良好的产品体验是吸引用户的首要因素，除去交互等体验外，无论是个人用户还是企业人员本身，甚至是爬虫机器人，都会对业务的响应性能有较高的要求。对于服务用户的产品来说，除了人性化的交付体验外，系统的响应时间也是非常重要的。根据eBay之前的统计，系统的性能指标会影响到用户的转化率，更快的系统也会带来更好的口碑，另外，高级的搜索系统也会根据系统的响应时间进行加权计算而影响相应的排名，因此打造良好的用户体验对一个成功的产品必不可少，当然前提是保证产品的基本可用。
· 移动互联网的突发性
随着移动互联网的技术发展，越来越多的人依赖于移动终端而生活，因此对业务的可用性提出了更高的要求，碎片化的时间使得用户能随时随地进行网络互联操作。另一方面，在节假日或者热点事件发生时，必须随时应对用户的突发访问压力，因此提高系统的非功能性要求也给技术人员在架构设计方面提出了新的挑战，相应地，也能为新业务提供更多的机会。
很明显，仅仅考虑快速验证和成本的投入因素，传统的软件生产方式根本无法满足产品对技术的发展要求，因此，使用“云”是目前所有公司的首要选择方案之一。然而，如果只是以资源为对象的方式来使用“云”，而不是以应用为中心、聚集于业务，将会导致效率非常低下，仍然无法满足用户快速迭代等需求，因此需要根据“云”的特点从架构上来进行设计，所以基于“云”的应用架构是所有技术人员从事开发必须考虑的首要条件。如何基于云计算平台设计出具有高扩展、高可用的架构来满足业务需求，创造更大的商业价值，也是原生应用架构设计的必经之路。那么，何为云原生应用？我们来一探究竟。1.3 云原生应用架构
云原生（Cloud Native）的概念，由来自Pivotal的Matt Stine于2013年首次提出，被一直延续使用至今。这个概念是Matt Stine根据其多年的架构和咨询经验总结出来的一个思想集合，并得到了社区的不断完善，内容非常多，包括DevOps、持续交付（Continuous Delivery）、微服务（Micro Services）、敏捷基础设施（Agile Infrastructure）和12要素（The Twelve-Factor App）等几大主题，不但包括根据业务能力对公司进行文化、组织架构的重组与建设，也包括方法论与原则，还有具体的操作工具。采用基于云原生的技术和管理方法，可以更好地把业务生于“云”或迁移到云平台，从而享受“云”的高效和持续的服务能力。
顾名思义，云原生是面向“云”而设计的应用，因此技术部分依赖于在传统云计算的3层概念（基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS）），例如，敏捷的不可变基础设施交付类似于IaaS，用来提供计算网络存储等基础资源，这些资源是可编程且不可变的，直接通过API可以对外提供服务；有些应用通过PaaS服务本来就能组合成不同的业务能力，不一定需要从头开始建设；还有一些软件只需要“云”的资源就能直接运行起来为云用户提供服务，即SaaS能力，用户直接面对的就是原生的应用。
应用基于云服务进行架构设计，对技术人员的要求更高，除了对业务场景的考虑外，对隔离故障、容错、自动恢复等非功能需求会考虑更多。借助云服务提供的能力也能实现更优雅的设计，比如弹性资源的需求、跨机房的高可用、11个9（99.999999999%）的数据可靠性等特性，基本是云计算服务本身就提供的能力，开发者直接选择对应的服务即可，一般不需要过多考虑本身机房的问题。如果架构设计本身又能支持多云的设计，可用性会进一步提高，比如Netflix能处理在AWS的某个机房无法正常工作的情况，还能为用户提供服务，这就是“云”带来的魔力，当然，云也会带来更多的隔离等问题。如图1-4所示，目前业界公认的云原生主要包括以下几个层面的内容。图1-4 云原生的内容
敏捷基础设施
正如通过业务代码能够实现产品需求、通过版本化的管理能够保证业务的快速变更，基于云计算的开发模式也要考虑如何保证基础资源的提供能够根据代码自动实现需求，并实现记录变更，保证环境的一致性。使用软件工程中的原则、实践和工具来提供基础资源的生命周期管理，这意味着工作人员可以更频繁地构建更强可控或更稳定的基础设施，开发人员可以随时拉取一套基础设施来服务于开发、测试、联调和灰度上线等需求。当然，同时要求业务开发具有较好的架构设计，不需要依赖本地数据进行持久化，所有的资源都是可以随时拉起，随时释放，同时以API的方式提供弹性、按需的计算、存储能力。
技术人员部署服务器、管理服务器模板、更新服务器和定义基础设施的模式都是通过代码来完成的，并且是自动化的，不能通过手工安装或克隆的方式来管理服务器资源，运维人员和开发人员一起以资源配置的应用代码为中心，不再是一台台机器。基础设施通过代码来进行更改、测试，在每次变更后执行测试的自动化流程中，确保能维护稳定的基础设施服务。
此外，基础设施的范围也会更加广泛，不仅包括机器，还包括不同的机柜或交换机、同城多机房、异地多机房等，这些内容也会在后续章节中逐一进行部分讨论。
持续交付
为了满足业务需求频繁变动，通过快速迭代，产品能做到随时都能发布的能力，是一系列的开发实践方法。它分为持续集成、持续部署、持续发布等阶段，用来确保从需求的提出到设计开发和测试，再到让代码快速、安全地部署到产品环境中。持续集成是指每当开发人员提交了一次改动，就立刻进行构建、自动化测试，确保业务应用和服务能符合预期，从而可以确定新代码和原有代码能否正确地集成在一起。持续交付是软件发布的能力，在持续集成完成之后，能够提供到预发布之类系统上，达到生产环境的条件，持续部署是指使用完全的自动化过程来把每个变更自动提交到测试环境中，然后将应用安全地部署到产品环境中，打通开发、测试、生产的各个环节，自动持续、增量地交付产品，也是大量产品追求的最终目的，当然，在实际运行的过程中，有些产品会增加灰度发布等环境。总之，它更多是代表一种软件交付的能力，过程示例请参考图1-5。图1-5 持续交付流程
DevOps
DevOps如果从字面上来理解只是Dev（开发人员）+Ops（运维人员），实际上，它是一组过程、方法与系统的统称，其概念从2009年首次提出发展到现在，内容也非常丰富，有理论也有实践，包括组织文化、自动化、精益、反馈和分享等不同方面。首先，组织架构、企业文化与理念等，需要自上而下设计，用于促进开发部门、运维部门和质量保障部门之间的沟通、协作与整合，简单而言组织形式类似于系统分层设计。其次，自动化是指所有的操作都不需要人工参与，全部依赖系统自动完成，比如上述的持续交付过程必须自动化才有可能完成快速迭代。再次，DevOps的出现是由于软件行业日益清晰地认识到，为了按时交付软件产品和服务，开发部门和运维部门必须紧密合作。总之，如图1-6所示，DevOps强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。图1-6 DevOps强调组织的沟通与协作
微服务
随着企业的业务发展，传统业务架构面临着很多问题。其一，单体架构在需求越来越多的时候无法满足其变更要求，开发人员对大量代码的变更会越来越困难，同时也无法很好地评估风险，所以迭代速度慢；其二，系统经常会因为某处业务的瓶颈导致整个业务瘫痪，架构无法扩展，木桶效应严重，无法满足业务的可用性要求；最后，整体组织效率低下，无法很好地利用资源，存在大量的浪费。因此，组织迫切需要进行变革。随着大量开源技术的成熟和云计算的发展，服务化的改造应运而生，不同的架构设计风格随之涌现，最有代表性的是Netflix公司，它是国外最早基于云进行服务化架构改造的公司，2008年因为全站瘫痪被迫停业3天后，它痛下决心改造，经过将近10年的努力，实现了从单架构到微服务全球化的变迁，满足了业务的千倍增长（如图1-7所示），并产生了一系列的最佳实践。图1-7 Netflix微服务化支撑业务千倍增长
随着微服务化架构的优势展现和快速发展，2013年，Martin Flower对微服务概念进行了比较系统的理论阐述，总结了相关的技术特征。首先，微服务是一种架构风格，也是一种服务；其次，微服务的颗粒比较小，一个大型复杂软件应用由多个微服务组成，比如Netflix目前由500多个的微服务组成；最后，它采用UNIX设计的哲学，每种服务只做一件事，是一种松耦合的能够被独立开发和部署的无状态化服务（独立扩展、升级和可替换）。微服务架构如图1-8所示。图1-8 微服务架构示例
由微服务的定义分析可知，一个微服务基本是一个能独立发布的应用服务，因此可以作为独立组件升级、灰度或复用等，对整个大应用的影响也较小，每个服务可以由专门的组织来单独完成，依赖方只要定好输入和输出口即可完全开发，甚至整个团队的组织架构也会更精简，因此沟通成本低、效率高。根据业务的需求，不同的服务可以根据业务特性进行不同的技术选型，是计算密集型还是I/O密集型应用都可以依赖不同的语言编程模型，各团队可以根据本身的特色独自运作。服务在压力较大时，也可以有更多容错或限流服务。
微服务架构确实有很多吸引人的地方，然而它的引入也是有成本的，它并不是银弹，使用它会引入更多技术挑战，比如性能延迟、分布式事务、集成测试、故障诊断等方面，企业需要根据业务的不同的阶段进行合理的引入，不能完全为了微服务而“微服务”，本书第5章也会对如何解决这些问题提供不同的方案。
12要素“12要素”英文全称是The Twelve-Factor App，最初由Heroku的工程师整理起步，是集体贡献总结的智慧，如图1-9所示。根据基于云的软件开发模式，12要素比较贴切地描述了软件应用的原型，并诠释了使用原生云应用架构的原因。比如，一个优雅的互联网应用在设计过程中，需要遵循的一些基本原则和云原生有异曲同工之处。通过强化详细配置和规范，类似Rails的基于“约定优于配置”（convention over configuration）的原则，特别在大规模的软件生产实践中，这些约定非常重要，从无状态共享到水平扩展的过程，从松耦合架构关系到部署环境。基于12要素的上下文关联，软件生产就变成了一个个单一的部署单元；多个联合部署的单元组成一个应用，多个应用之间的关系就可以组成一个复杂的分布式系统应用。图1-9 12要素
下面简要介绍图 1-9中的这些原则。相信很多开发者在实际开发工作中已经很好地应用了其中的一些原则，只是没有意识到概念本身。对这些原则比较陌生的开发者，如果想了解更多的操作过程，请在互联网上搜索《云原生时代下的12要素（12-Factor）应用与实践》一文作为参考。
· 基准代码
每一个部署的应用都在版本控制代码库中被追踪。在多个部署环境中，会有多种部署实例，单个应用只有一份代码库，多份部署相当于运行了该应用的多个实例，比如开发环境一个实例，测试环境、生产环境都有一个实例。
实际上，在云计算架构中，所有的基础设施都是代码配置，即 Infrastructure as Code（IaC），整个应用通过配置文件就可以编排出来，而不再需要手工的干预，做到基础服务也是可以追踪的。
· 依赖
应用程序不会隐式依赖系统级的类库，通过依赖清单声明所有依赖项，通过依赖隔离工具确保程序不会存在调用系统，但清单中未声明依赖项，清单统一应用到生产和开发环境。比如通过合适的工具（例如 Maven、Bundler、NPM），应用可以很清晰地对部署环境公开和隔绝依赖性，而不是模糊地对部署环境产生依赖性。
在容器应用中，所有应用的依赖和安装都是通过Docker File来完成声明的，通过配置能明确把依赖关系，包括版本都明确地图形化展示出来，不存在黑盒。
· 配置
环境变量是一种清楚、容易理解和标准化的配置方法，将应用的配置存储于环境变量中，保证配置排除在代码之外，或者其他可能在部署环境（例如研发、展示、生产）之间区别的任何代码，可以通过操作系统级的环境变量来注入。
实例根据不同的环境配置运行在不同的环境中，此外，实现配置即代码，在云环境中，无论是统一的配置中心还是分布式的配置中心都有好的实践方式，比如Docker的环境变量使用。
· 后端服务
不用区别对待本地或第三方服务，统一把依赖的后端作为一种服务来对待，例如数据库或者消息代理，作为附加资源，同等地在各种环境中被消耗。比如在云架构的基础服务中，计算、网络、存储资源都可以看作是一种服务去对待使用即可，不用区分是远程还是本地的。
· 构建、发布、运行
应用严格区分构建、发布、运行这3个阶段。3个阶段是严格分开的，一个阶段对应做一件事情，每个阶段有很明确的实现功能。云原生应用的构建流程可以把发布配置挪到开发阶段，包括实际的代码构建和运行应用所需的生产环境配置。在云原生应用中，基于容器的Build-Ship-Run和这3个阶段完全吻合，也是Docker对本原则的最佳实践。
· 进程
进程必须无状态且无共享，即云应用以一个或多个无状态不共享的程序运行。任何必要状态都被服务化到后端服务中（缓存、对象存储等）。
所有的应用在设计时就认为随时随地会失败，面向失败而设计，因此进程可能会被随时拉起或消失，特别是在弹性扩容的阶段。
· 端口绑定
不依赖于任何网络服务器就可以创建一个面向网络的服务，每个应用的功能都很齐全，通过端口绑定对外提供所有服务，比如Web应用通过端口绑定（Port binding）来提供服务，并监听发送至该端口的请求（包括HTTP）。
在容器应用中，应用统一通过暴露端口来服务，尽量避免通过本地文件或进程来通信，每种服务通过服务发现而服务。
· 并发
进程可以看作一等公民，并发性即可以依靠水平扩展应用程序来实现，通过进程模型进行扩展，并且具备无共享、水平分区的特性。
在互联网的服务中，业务的爆发性随时可能发生，因此不太可能通过硬件扩容来随时提供扩容服务，需要依赖横向扩展能力进行扩容。
· 易处理
所有应用的架构设计都需要支持能随时销毁的特点，和状态的无关性保持一致，允许系统快速弹性扩展、改变部署及故障恢复等。
在云环境中，由于业务的高低峰值经常需要能实现快速灵活、弹性的伸缩应用，以及不可控的硬件因素等，应用可能随时会发生故障，因此应用在架构设计上需要尽可能无状态，应用能随时随地拉起，也能随时随地销毁，同时保证进程最小启动时间和架构的可弃性，也可以提供更敏捷的发布及扩展过程。
· 环境等价
必须缩小本地与线上差异，确保环境的一致性，保持研发、测试和生产环境尽可能相似，这样可以提供应用的持续交付和部署服务。
在容器化应用中，通过文件构建的环境运行能做到版本化，因此保证各个不同环境的差异性，同时还能大大减少环境不同带来的排错等成本沟通问题。
· 日志
每一个运行的进程都会直接标准输出（stdout）和错误输出（stderr）事件流，还可以将日志当作事件流作为数据源，通过集中服务，执行环境收集、聚合、索引和分析这些事件。
日志是系统运行状态的部分体现，无论在系统诊断、业务跟踪还是后续大数据服务的必要条件中，Docker提供标准的日志服务，用户可以根据需求做自定义的插件开发来处理日志。
· 管理进程
管理或维护应用的运行状态是软件维护的基础部分，比如数据库迁移、健康检查、安全巡检等，在与应用长期运行的程序相同环境中，作为一次性程序运行。
在应用架构模式中，比如Kubernetes里面的Pod资源或者docker exec，可以随着其他的应用程序一起发布或在出现异常诊断时能通过相关的程序去管理其状态。
云原生的内容非常广泛，目前没有系统的说明和完整的定义，上文介绍了云原生应用的基础组件和相关特点，可能读者对云原生应用的逻辑还存在一些困惑。为了更清楚地进行说明，我们总结了其依赖关系，如图1-10所示。图1-10 云原生内容的依赖关系
首先，为了抓住商业机会，业务需要快速迭代，不断试错，因此，企业需要依赖拥有持续交付的能力，这些不仅包括技术需求还包括产品的需求，如何能拥有持续交付的能力，大而全的架构因为效率低下，显然是不合适的。于是演变出微服务架构来满足需求，通过把系统划分出一个个独立的个体，每个个体服务的设计依赖需要通过12要素的原则来规范完成。同样，如果系统被分成了几十个甚至几百个服务组件，则需要借助 DevOps才能很好地满足业务协作和发布等流程。最后，DevOps的有效实施需要依赖一定的土壤，即敏捷的基础设施服务，现实只有云计算的模式才能满足整体要求。通过上述梳理，我们总结出面向云原生应用的3个不同层次的特点。
· 高可用设计（Design for Availability），依据应用业务需求，高可用分为不同级别，比如不同区域、不同机房（跨城或同城）、不同机柜、不同服务器和不同进程的高可用，云原生应用应该根据业务的可用性要求设计不同级别的架构支持。
· 可扩展设计（Design for Scale），所有应用的设计是无状态的，使得业务天生具有扩展性，在业务流量高峰和低峰时期，依赖云的特性自动弹性扩容，满足业务需求。
· 快速失败设计（Design for Failure），即包括系统间依赖的调用随时可能会失败，也包括硬件基础设施服务随时可能宕机，还有后端有状态服务的系统能力可能有瓶颈，总之在发生异常时能够快速失败，然后快速恢复，以保证业务永远在线，不能让业务半死不活地僵持着。
通过上面的基本描述及云原生应用的组成或特点，与容器技术（第2章将详细介绍）相比可以得知，容器的特性天生就是按这些原则进行设计的。随着互联网业务的架构不断演进，从单体应用到分布式应用，甚至微服务架构应用中，12要素较好地为构建互联网化应用提供了统一的方法论和标准化，具有强大的生命力，每一条原则都是应用开发的珠玑。当然，在实践过程中，每一个原则也不是一成不变的，随着新的理念和技术出现，原有的因素会得到延伸和发展，会出现新的原则和应用，这套理论也适用于任意语言和后端服务（数据库、消息队列、缓存等）开发的应用程序，因此也作为云原生架构应用的基本指导原则之一。1.4 架构演化发展历程
目前，互联网企业随着业务的发展不断前进。因此，不同的阶段有不同的需求，所以需要使用不同的方法来聚焦不同的目的。比如初创型的企业需要抓住合适的机遇快速进行原型验证，证明大的方向没问题才有可能进一步发展。因此技术一般是为了满足业务的发展和验证而设计，只要保证共用的组件能够复用就可以。只有随着业务的进一步发展，组织架构及人员的规模越来越大，企业才有机会发展成中型或独角兽公司。然而协作人员数量的增长也意味着新的问题，一般而言，只要企业的人员规模超过150人，就会带来极大的管理成本提升。在这一阶段，技术不仅需要和产品进行更充分的结合，还需要规范化和工程化操作。当规模再次扩大的时候，如果只是简单的人力堆积，协调性问题是无法解决的，企业需要更高效的架构才能支撑和反哺业务的发展，工具和流程需要更加自动化才有可能保证业务的持续发展，边际效应非常明显，同时挑战也更大。
总之，在任何阶段，技术的演进都是一个非常重要的过程，这一点在以技术为导向的公司尤为凸显。技术超前就有可能成为先行者，技术落后就有可能导致企业发展缓慢，机会丢失。
无论是个人开发者还是技术公司，如果目的是持续运行和发展，就需要一套良好并固定的制度，同样，在技术上，团队的持续前进离不开项目的工程化思维。开发、测试、发布的软件生命周期的高效管理必须依赖工程化，它是研发协作与云端运维的基础。这里面包括许多问题，需要技术人员去解决，比如：追求技术的先进或业务需求的合理性评估，可能是很多公司技术管理需要根据组织架构权衡的问题。一般来讲，任何从零起步的公司都会经过不同的技术发展阶段，包括简单的初创期、快速增长期及分布式的服务化架构阶段。每个阶段对应不同的产品和业务需求，技术承担不同职责，需要技术人员来决策，尤其是架构师需要思考这些问题。1.4.1 初创期架构
创业公司在开始新业务的时期，基本处在试错或原型验证阶段，这个阶段更多是关注业务的本身是否有前景或商业模式，而不会把非常多的精力放在技术的系统架构上，尤其是对于非技术型或不确定型的项目立项阶段。尽管很多技术人员也预料到前期需要很多时间去好好设计系统，才能保证支撑后续可能的业务快速发展，但往往由于时间成本或人力等原因而无法很好地执行。
一般来讲，创业型的项目对时间的要求非常苛刻，需要在3到6个月时间内完成系统的上线，否则有可能由于业务无法快速上线验证，导致无法获取相关的原始数据进行下一个目标验证，更严重的有可能造成资金链的断裂。罗马不是一天建成的，因此这个阶段会使用相对简单的架构方式来进行设计，本节先从最主要的几点进行说明，更详细内容请参考第3章。
单体架构
对于创业型公司来说，由于人才、技术、资金等重要因素的影响，同时，技术人员为了配合产品的需求，会采用最简单的架构来完成最原始阶段开发。根据我们接触的不少用户反馈，有些企业考虑成本因素，甚至只使用一台服务器或者容器服务。另外，传统官网、论坛等应用，由于早期的设计采用了单体架构来实现，只需要一台服务器或容器来服务即可。对于其他的应用服务器、数据库、静态文件等资源，也是部署到同一台服务器或容器上来服务。最简单的架构模型如图1-11所示。图1-11 最简单的架构模型
对于早期的单体应用，应用服务+数据库服务基本上就组成了最原始的架构模型，技术人更多会考虑技术的选型，包括编程语言、版本管理、数据库的类型等。比如PHP的开发者选择PHP+MySQL，Java的开发者采用Tomcat+MySQL等开发方式。
服务器分离
根据线上运行经验，一般的业务的类型，如果每日的用户访问量在百万级别以内，只要进行简单的Web应用性能参数调优、数据库索引优化等，基本上就能保证服务的稳定运行。当然，随着访问量的不断增加，部署在同一台服务器上的应用及数据库服务，会造成服务器的CPU/内存/磁盘/带宽等系统资源竞争，从而相互影响。显然很容易出现性能瓶颈，如果这台服务器出现了宕机或无法恢复的错误，就有可能导致全站不可访问或者数据丢失等情况，后果非常严重，因此大部分产品会将Web应用服务器和数据库服务器进行物理分离，独立部署，相互热备提供服务，只需要增加很少的成本，就能解决对应性能和数据的可靠性等问题。
初期由于各种条件存在，不能很好地进行新项目前景的预见，技术人员如果能在最小成本的情况下保证架构的合理性，还能很好地服务产品功能需求，甚至只要在部署架构上稍做调整，就可以防止出现灾难性的问题，这其中也包括很多技术架构上的考虑。
业务模型
一般而言，现阶段的业务比较简单，产品也比较单一，业务会随时根据其运营数据进行调整，因此，这时需要技术人能够较好地把不同的模块分离出来，对于偏业务相关的功能，需要有较好的心态接收随时变化的不确定性，对于后续可能复用或大量依赖的工程，需要进行较好的设计，否则可能在业务爆发时导致业务开发的进度越来越
试读结束[说明：试读内容隐藏了图片]