软件系统的架构/部署方式：单体、分布式、SOA、微服务

什么是软件架构？软件架构是什么？

• “架构”在现实世界中被很多行业所使用，很难有一个明确或标准的定义；但架构是必须要考虑的问题，有系统的地方就需要架构，大到航空飞机，小到一个电商系统里面的一个功能组件，都需要设计和架构。
• 抽象而言，架构就是对系统中的实体以及实体之间的关系所进行的抽象描述，是对物/信息的功能与形式元素之间的对应情况所做的分配，是对元素之间的关系以及元素同周边环境之间的关系所做的定义。
• 架构能将目标系统按某个原则进行切分，切分的原则，是要便于不同的角色进行并行工作，结构良好的创造活动要优于毫无结构的创造活动。

软件架构分类

• 业务架构（需求和解决方案架构）：核心是针对具体业务，了解客户/业务方的痛点，项目定义，现有环境；梳理实际需求和非功能性需求，进行问题域划分与领域建模等工作；沟通协调，方案拟定于需求建议，需求迭代，项目交付等。
• 应用架构：专注对整个应用系统的核心处理逻辑进行描述，根据业务场景的需要，设计应用的层次结构，制定应用规范、定义接口和数据交互协议等。并尽量将应用的复杂度控制在一个可以接受的水平，从而在快速的支撑业务发展的同时，在保证系统的可用性和可维护性的同时，确保应用满足非功能属性要求（性能、安全、稳定性等）。
• 数据架构：专注于构建数据处理逻辑，统一数据定义规范，标准化数据表达，形成有效易维护的数据资产。打造统一的大数据处理平台，包括数据可视化运营平台、数据共享平台、数据权限管理平台等。
• 中间件架构：专注于中间件系统的构建，需要解决服务器负载，分布式服务的注册和发现，消息系统，缓存系统，分布式数据库等问题，同时架构师要在 CAP 之间进行权衡。
• 运维架构：负责运营维护系统的规划、选型、部署上线，建立规范化的运维体系。
• 物理架构：物理架构关注软件元件是如何操作和部署到硬件上的，专注于基础设施，某种软硬件体系，甚至云平台，包括机房搭建、网络拓扑结构，网络分流器、代理服务器、Web 服务器、应用服务器、报表服务器、整合服务器、存储服务器和主机等。
• 技术架构：专注对系统中各个实现层面的具体实现进行描述（从技术层面描述系统实现），主要是分层模型，例如持久层、数据层、逻辑层、应用层、表现层等，然后每层使用什么技术框架：PHP、Spring、hibernate、ioc、MVC、成熟的类库、中间件、WebService等，分别说明，要求这些技术能够将整个系统的主要实现概括。

应用架构发展历程

1. 单体架构
2. 分布式架构
3. SOA架构
4. 微服务架构
5. Serverless架构（云计算平台整合架构）
6. Cloud Native 云原生架构（云计算平台整合架构）

单体架构

• 单体架构在技术架构的层面上又分为标准的三层：数据访问层（M）、服务层（C）和 Web（控制层V）层，简称MVC。
• 数据访问层用于定义数据访问接口，实现对真实数据库的访问；
• 服务层用于对应用业务逻辑进行处理；
• Web 层用于处理异常、逻辑跳转控制、页面渲染模板等。

由来：

• 最简单的应用架构逻辑，符合人类的第一认知思路，以“实现功能”为主，适用于构建数据、处理数量达不到海量级别的小中型软件系统。
• 软件发展的最开始，各大互联网公司的应用技术栈大致可分为 LAMP（Linux + Apache + MySQL + PHP）和 MVC（Spring + iBatis/Hibernate + Tomcat）和 .NET（.NET MVC） 三大流派。无论是 LAMP 还是 MVC，都是为单体应用架构设计的，其优点是学习成本低，开发上手快，测试、部署、运维也比较方便，甚至一个人就可以完成一个网站的开发与部署。

优点：

• 易于搭建开发环境、易于测试、易于部署
• 开发方便，运维方便

缺点：

• 无法进行局部改动与部署
• 编译时间过长
• 技术缺陷、债务越来越多：随着时间推移、需求变更和人员更迭，会在应用程序中形成越来越多的缺陷而无法彻底修复。“不坏不修”，这在软件开发中非常常见，在单体应用中这种思想更甚。已使用的系统设计或模块代码难以被整体修改（这些代码可能存在缺陷），因为应用程序中的其他模块可能会以各种各样的方式使用它。
• 回归测试周期过长
• 开发效率降低
• 维护升级复杂性高：以一个百万行代码级别的单体应用为例，整个项目包含的模块非常多、模块的边界模糊、依赖关系不清晰、代码质量参差不齐、混乱地堆砌在一起。可想而知整个项目非常复杂。每次修改代码都心惊胆战，甚至添加一个简单的功能，或者修改一个Bug都会带来隐含的缺陷。
• 部署频率低：随着代码的增多，构建和部署的时间也会增加。而在单体应用中， 每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。全量部署的方式耗时长、 影响范围大、 风险高， 这使得单体应用项目上线部署的频率较低。 而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复，出错率比较高。
• 容错性、可靠性差：某块代码中的Bug：死循环、内存溢出等，都会导致整个应用的崩溃。
• 灵活性、扩展能力差：单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。例如：应用中有的模块是计算密集型的，它需要强劲的CPU；有的模块则是IO密集型的，需要更大的内存。由于这些模块部署在一起，不得不在硬件的选择上做出妥协，使用了统一的技术平台或方案解决所有的问题， 团队中的每个成员都必须使用相同的开发语言和框架，要想引入新框架或新技术平台也会非常困难。

分布式架构

由来：

• 增大系统吞吐量：当数据处理、请求数量达到一定级别后，单体架构的系统已经供不应求了，超出了一台服务器的最高处理要求，需要将应用系统进行模块拆分（水平拆分和垂直拆分）分别部署到多个服务器上，使用负载均衡调度工具进行协调处理。
• 增强系统可用性：业务处理越来越关键，需要提高整个系统架构的可用性，这就意味着架构中不能存在单点故障。这样，整个系统不会因为一台机器出故障而导致整体不可用。所以，需要通过分布式架构来冗余系统以消除单点故障，从而提高系统的可用性。

优点：

• 低耦合度：把模块拆分，使用接口通信，降低模块之间的耦合度。
• 开发效率高：把项目拆分成若干个子项目，不同的团队负责不同的子项目，提高了开发效率。
• 扩展方便：增加功能时只需要再增加一个子项目，调用其他系统的接口就可以。
• 部署灵活：可以灵活的进行分布式部署。
• 代码复用性高：因为功能的模块化，所以系统模块重用度更高

缺点: 

• 系统之间的交互要使用远程通信，接口开发增大工作量
• 开发难度高：分布式部署会带来如：各个拆分开的模块间如何相互调用、会话的统一管理、一致性更新、分布式事务、关键服务的可用性保障等一系列问题，加大了开发复杂度

分布式和集群

• 分布式：一个业务拆分成多个子业务，部署在不同的服务器上
• 集群：同一个业务，部署在多个服务器上
• 如：电商系统可以拆分成商品，订单，用户等子系统，这就是分布式；而为了应对并发，同时部署好几个用户系统，这就是集群

面向服务的SOA架构

• 将多个模块分成多个子系统，多个子系统在服务总线上进行登记，通过服务总线来实现均衡调用（因为SOA一般用于大型项目，比较复杂，所以一般总系统不会再集成，会拆分多个，分别做成服务，相互调用）。
• 当我们进行下订单的任务处理时，多个服务直接互相调用，系统通过服务总线，分别调用对于的子系统来完成任务处理。
• 企业服务总线：企业服务总线不是对多个子模块的集成，他在这里充当数据通道的作用，数据总线不关心业务，数据总线根据给的地址和协议去调服务，上端不关心服务在哪里是什么，只找数据总线。

由来：

• 实现服务（独立功能模块）的可治理：随着系统的数据处理、请求数量进一步增加，会拓展更多的服务器进行集群，这样我们会发现这些服务器会越来越难以管理，那些服务器可用？那些功能模块需要进一步提高扩展？等等一系列问题都会发生，这时候需要对所有的服务器进行管理、监视来达到更好的数据和请求的处理。

优点：

• 松耦合：由于服务自治，有一定封装边界，服务调用交互是通过发布接口。这意味着应用程序不感兴趣的服务如何被实现。
• 位置透明：服务的消费者不必关系服务位于什么地方。
• 可在异构平台间复用。可以将遗留系统包装成服务。
• 便于测试，能并行开发，较高可靠性和良好可伸缩性。
• 降低用户成本，用户不需要关心各服务之间是什么语言的、不需要知道如果调用他们，只要通过统一标准找数据总线就可以了。

缺点：

• 提高了系统的复杂程度，性能有相应影响。

微服务架构

• 对于微服务，不同背景的人也有不同的见解，对于熟悉 SOA 的开发者，微服务是去中心化的分布式软件架构。SOA 更多强调重用，而微服务偏向于重写。SOA 偏向水平服务，
• 微服务偏向垂直服务；SOA 偏向自上而下的设计，微服务偏向自下而上的设计。
• 微服务与软件工程，面向对象设计中的原理同样相通，都是遵循单一职责(Single Responsibility)、关注分离(Separation of Concerns)、模块化(Modularity)与分而治之(Divide & Conquer)等基本的原则。

由来：

• 模块细分化、多层次服务治理与监管：在SOA的基础上进一步将模块细分，添加了更多的服务治理中间组件：负载均衡、熔断、限流和降级、服务注册中心、API网关等等
• SOA灵活性差：由于SOA架构早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，如：J2EE。这导致很多企业的遗留系统很难对接，切换时间太长，成本太高，新系统稳定性的也需要时间去检验。最终 SOA 成为了企业级的重量级架构方案，中小公司都不敢尝试。

优点：

• 易于开发和维护：一个微服务只会关注一个特定的业务功能，所以它业务清晰、代码量较少。开发和维护单个微服务相对简单。而整个应用是由若干个微服务构建而成的，所以整个应用也会被维持在一个可控状态。
• 单个微服务启动较快：单个微服务代码量较少，所以启动会比较快。
• 局部修改容易部署：单体应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。
• 技术栈不受限：在微服务架构中，可以结合项目业务及团队的特点，合理地选择技术栈。例如某些服务可使用关系型数据库MySQL；某些微服务有图形计算的需求，可以使用Neo4j；甚至可根据需要，部分微服务使用Java开发，部分微服务使用Node.js开发。

缺点：

• 微服务虽然有很多吸引人的地方，但它并不是免费的午餐，使用它是有代价的。使用微服务架构面临的挑战。
• 运维要求较高：更多的服务意味着更多的运维投入。在单体架构中，只需要保证一个应用的正常运行。而在微服务中，需要保证几十甚至几百个服务服务的正常运行与协作，这给运维带来了很大的挑战。
• 分布式固有的复杂性：使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的挑战。
• 接口调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有使用了该接口的微服务都需要做调整。
• 重复劳动：很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，从而导致代码重复。尽管可以使用共享库来解决这个问题（例如可以将这个功能封装成公共组件，需要该功能的微服务引用该组件），但共享库在多语言环境下就不一定行得通了。

Serverless架构（功能模块商业化）

由来：

• 云计算FaaS和BaaS的构建：由第三方平台提供一些模块功能服务，这些模块服务由第三方平台维护，我们只需要购买各种服务即可，就如我们购买水电一样，出现任何问题可以找第三方解决，人们不再操心运行所需的资源，只需关注自己的业务逻辑，并且为实际消耗的资源付费。可以说，随着Serverless架构的兴起，真正的云计算时代才算到来了。
• BaaS（Backend as a Service，后端即服务）是指我们不再编写或管理所有服务端组件，可以使用领域通用的远程组件（而不是进程内的库）来提供服务。
• FaaS意在无须自行管理服务器系统或自己的服务器应用程序，即可直接运行后端代码。

优点：

• 低运营成本：在业务突发性极高的场景下，系统为了应对业务高峰，必须构建能够应对峰值需求的系统，这个系统在大部分时间是空闲的，这就导致了严重的资源浪费和成本上升。在微服务架构中，服务需要一直运行，实际上在高负载情况下每个服务都不止一个实例，这样才能完成高可用性；在Serverless架构下，服务将根据用户的调用次数进行计费，按照云计算pay-as-you-go原则，如果没有东西运行，你就不必付款，节省了使用成本。同时，用户能够通过共享网络、硬盘、CPU等计算资源，在业务高峰期通过弹性扩容方式有效的应对业务峰值，在业务波谷期将资源分享给其他用户，有效的节约了成本。
• 简化设备运维：在原有的IT体系中，开发团队即需要维护应用程序，同时还要维护硬件基础设施；Serverless架构中，开发人员面对的将是第三方开发或自定义的API 和URL，底层硬件对于开发人员透明化了，技术团队无需再关注运维工作，能够更加专注于应用系统开发。
• 提升可维护性：Serverless架构中，应用程序将调用多种第三方功能服务，组成最终的应用逻辑。目前，例如登陆鉴权服务，云数据库服务等第三方服务在安全性、可用性、性能方面都进行了大量优化，开发团队直接集成第三方的服务，能够有效的降低开发成本，同时使得应用的运维过程变得更加清晰，有效的提升了应用的可维护性。
• 更快的开发速度：这一点在现在互联网创业公司得到很好的体现，创业公司往往开始由于人员和资金等问题，不可能每个产品线都同时进行，这时候就可以考虑第三方的Baas平台，比如使用微信的用户认证、阿里云提供的RDS，极光的消息推送，第三方支付及地理位置等等，能够很快进行产品开发的速度，把工作重点放在业务实现上，把产品更快的推向市场。

缺点：

• 厂商平台绑定：平台会提供Serverless架构给大玩家，比如AWS Lambda，运行它需要使用AWS指定的服务，比如API网关，DynamoDB，S3等等，一旦你在这些服务上开发一个复杂系统，你会粘牢AWS，以后只好任由他们涨价定价或者下架等操作，个性化需求很难满足，不能进行随意的迁移或者迁移的成本比较大，同时不可避免带来一些损失。Baas行业内一个比较典型的事件，2016年1月19日Facebook关闭曾经花巨额资金收购的Parse，造成用户不得不迁移在这个平台中产生一年多的数据，无疑需要花费比较大的人力和时间成本。
• 成功案例比较少，没有行业标准：目前的情况也只适合简单的应用开发，缺乏大型成功案例的推动。对于Serverless缺乏统一的认知以及相应的标准，无法适应所有的云平台。
• 目前微服务架构在四种架构中处于主流地位，很多应用第一、第二种架构的企业也开始慢慢转向微服务架构。到目前为止微服务的技术相对于二三年前已经比较成熟，第四种架构将是未来发展的一种趋势。如果你喜欢我的文章，欢迎关注我的简书，后续我将教会大家利用spring cloud和docker轻松愉快的构建微服务。

Cloud Native 云原生架构（功能模块商业化）

• Codeless 对应的是服务开发，实现了源代码托管，你只需要关注你的代码实现，而不需要关心你的代码在哪，因为在整个开发过程中你都不会感受到代码库和代码分支的存在。
• Applicationless 对应的是服务发布，在服务化框架下，你的服务发布不再需要申请应用，也不需要关注你的应用在哪。
• Serverless 对应的则是服务运维，有了 Serverless 化能力，你不再需要关注你的机器资源，Servlerless 会帮你搞定机器资源的弹性扩缩容