开发者学习笔记【阿里云云原生助理工程师认证（ACA）课程：微服务和 Serverless 架构-企业应用架构的演进】
课程地址：https://edu.aliyun.com/course/3112075/lesson/19022
微服务和 Serverless 架构-企业应用架构的演进
内容介绍
一、企业应用架构的演进
二、早期企业应用架构——单体应用
三、初步服务化应用架构——SOA
一、企业应用架构的演进
企业级应用架构发展历程，通过对云计算的基础知识的了解和之前云原生课程的学习，已经了解到过去的十年是云计算蓬勃发展，快速推进的十年，大量的企业从自驾 idc 机房或租用 idc 机房的 it 建设模式转到了通过云服务厂商来租用硬件资源的模式，这种将 it 设备服务化的方式对企业的 it 架构的影响是极其深远的。
首先，这种模式抛弃了传统 it 基础设施搭建中建设，购买，调试，运维等耗时耗力的环节，而是改为了随用随开的租用方式，大大降低了企业的 it 投入成本，其次，在设备日常维护中不再消耗精力，自建运维团队，而是转向了借用云服务厂商的强大运维能力，实现设备领域为从而大大提高了运维的效率和安全性。
同时，随着互联网行业发展，大量新的应用形态层出不穷，尤其是在移动互联网生态出现之后，互联网应用摆脱了传统的 PC 机环境。随着手机的普及走进了普通人一天 24 小时中，这使得互联网应用的用户数和用户使用时长都呈现了井喷式的发展趋势，在 it 硬件架构实施部署方式的变化和互联网应用生态快速发展的环境下，导致了传统的企业应用软件架构受到了巨大的挑战，为了能够更加适应外部环境和需求的变化，软件架构也在不断的进行着变化和演进。演进的过程分为三个阶段，从最开始的单体服务架构逐步进化，到初步化服务架构，到微服务架构。
二、早期企业应用架构——单体应用
软件架构演化的历史，首先是早期的单体应用架构，该架构下开发人员开发完所有模块之后会把所有的功能集合到一个单一的文件或者应用里面，然后再用 Qa 人员进行测试。测试完毕后再交给运维人员进行部署。
这种模式的特点可以归纳为三点，首先所有功能模块集中在一个应用里，这种情况下，模块和模块之间的功能互相调用比较紧密，边界并不是非常的明显，正是因为这种情况，单体应用会采用单一的开发语言进行开发，避免跨编程语言调用时出现一些比较复杂的情况，第二点是这种模式一般采用瀑布式开发流程。
瀑布式开发流程一般包括需求评审，架构设计功能细化，编码开发，功能测试，集中测试部署实施几个步骤，这种流程的特点是它的每一步边界非常明确，但是相对的开发周期会比较长，小一点的项目可能是 3~4 个月，稍大一点的项目时间会更长，甚至一年两年都是很常见的情况，第三个特点就是单体应用的开发模式下，开发人员，QA 人员和运维人员都分在不同的小组里面，每个小组的内部都有自己的工作流程，小组和小组之间的边界也相对比较清晰。
小组之间的配合，用比较详实的文档和审批流程进行连接。该单体式架构应用对于一些功能相对简单或者功能虽然复杂，一次性可以把功能全部设计清晰，并不需要反复迭代的场景下，它具有比较简洁，直观，好掌控的特性。
虽然迭代周期相对比较长，但流程很严谨，每一步都有详实扎实的文档进行质量把控，但是现在的互联网应用的应用场景和这种传统单体式应用所擅长的场景有很大的不同。
首先，互联网应用场景下，它的功能迭代速度要求非常快，一个新功能的上线可能是按周天甚至精确到小时来计算，其次就是互联网应用的功能会非常复杂，而且这些功能很难一次性把它全部设计清楚，该情况单体应用架构的一些缺点就暴露出来。
其中主要的缺点有如下几点，第一个缺点是迭代速度慢，沟通成本高。瀑布流程它的核心在于每一步流程都有详实的文档作为支撑，部门和部门之间通过审批进行关联，当一个功能需要快速推进时，浪费在审批流程和文档上的时间就会非常的多。
举例：当模块一需要做一个非常紧急的修改，而模块一的修改要依赖一个公共模块添加某些功能，但公共模块正在为模块 2 做一个大的重构和调整。此时模块的开发人员就需要和模块二和公共模块的开发人员进行文档和流程沟通。希望他们能放下手头的工作，先为他们的模块的某一个小功能做修改，而且还要通知 QA 和运维人员修改他们的工作计划,以配合紧急修改的上限。
第二是单体应用，所有功能都集中在一个运动里面。模块和模块之间的关系是比较紧密的，这种情况一般称为模块耦合度比较高，如果在功能一次性设计清晰的情况下，问题可以解决，但是在功能反复地添加修改，删除，变更的时候就会产生很大的问题。
举例:在程序最开始设计的时候，模块之前的耦合关系虽然紧密，但是区分还是非常清晰而且开发人员对这里面的细节也非常了解，但随着项目的推进，修改的次数越来越多，功能区分已经变得模糊起来，再加上旧有模块的开发人员慢慢流动，这种情况下，新来的开发人员对旧模块之间的互相依赖关系往往并不十分的了解，因此也不敢轻易对模块进行修改，因为经常会出现只做了某一些小的修改，就会导致前后关联大量模块功能异常的情况。这种情况就形成了无法轻易修改的祖传代码，从软件架构上来看，这也是一个不具有良好的扩展性的软件架构。
第三点这种单一单体应用架构还存在一个重大的风险，代码开发产生的 bug 除了模块内部的逻辑 bug，还有一大类 bug，为系统性 bug。
比如常见的内存泄漏以及不当使用系统资源，比如说资源死锁或者连接的数据库忘记释放，这种系统性的 bug，一旦出现会对整个应用的进程产生一个严重的影响，虽然可通过严格的测试和代码准备来避免这种情况，但是在互联网应用场景下，它的迭代速度非常快，留给 QA 人员的时间并不是很多，应用模块的数量会非常非常多。如果是十几个几十个模块，还可以通过质量控制的手段把它限制成小概率事件，但是当模板达到成千上万时，即使是 1%甚至千分之 1 的概率出现的比率也是非常高的，而一旦出现这种系统性 bug，它所导致的后果就会非常的严重，也就是整个应用全部不可用这种风险是任何项目都无法承受的。
三、初步服务化应用架构——SOA
随着软件功能的进一步丰富和用户规模的逐步扩大，在 2000 年左右，各大企业级应用软件在软件架构上也开始做了一些初步化的服务尝试，出现了 SOA 为代表的一批分布式服务化软件架构。SOA 架构最大的特点是在整个的应用里面引入了一个叫 ESB，也就是企业服务总线的中间件。各模块之间的功能并不是直接的耦合在一起，所有的跨模块调用都通过 ESB 进行转发，各个模块在开发完毕后也并不是部署在一个单一的应用里面，而是可以部署在不同的应用甚至不同的服务器上。
1、特点
这样做可以避免单体应用架构下的很多问题，首先最大的特点模块和模块之间的结构，不同的模块部署在不同的应用里面。
所有模块之间的关联关系都会通过 esb 显示的表现出来。这使得模块和模块之间的边界变得非常的清晰，也不存在单体用下公共变量、公共资源系统环境等隐形的关联关系。另外，每个模块都可以根据自己的功能特点选择更合适的开发语言，也可以使也可以根据自己的进度进行单独的迭代，对一些公共模块甚至可以在 esb 上同时部署多个版本， 支持不同模块之间不同的迭代需求，对一些历史遗留的旧系统也不用过多关注他的开发语言和内部技术，实现只需要把它的接口固定下来，其他的模块就可以通过标准的接口和他进行通信。这种架构在当时是一个非常先进的技术路线。
2、缺点
经过将近 10 年的发展，SOA 架构也慢慢显露出它内部的一些问题。首先就是这种架构存在一个明显的单点 ESB，ESB 在分布式调用的时候，它的重要性和吞吐量都是非常高的。
ESB 整个系统都无法进行一个有效的运转，这对于系统的健壮性来讲是一个巨大的风险，同时，这种流量转发的模式每次调用都要经过至少 4 次的网络通讯，从调用者发给 ESB,ESB 发给体重 ESB 发送给提供者在提供者将结果返回给 ESB ，ESB再返回给调用者，这对于并发量非常大的互联网应用来讲，性能损失是非常巨大的。
最后 SOA 模式，更多的侧重关注于分布式服务之间的调用，对于服务生命周期的管理，如服务的部署，配置，弹性伸缩等，缺少相应的支持。
