软件架构之四种类型简介
架构类型以及软件架构逻辑详解
架构类型以及软件架构逻辑详解架构类型：分布式、SOA架构、单体式。
分布式架构分布式应用架构中，相互独立，代码独立开发，独立部署，通过API接口互相通信。
通讯协议一般使用HTTP，数据格式是JSON( 是一种轻量级的数据交换格式)，应用集成方式比较简化。
优点: 应用内部高内聚，独立开发、测试和部署，应用之间松耦合，业务边界清晰，业务依赖明确，支持大项目并行开发。
缺点: API接口需求变化，应用就需要重新部署，通信可靠性和数据的封装性相对于进程内调用比较差。
SOA架构[现在也流程SAAS服务模式架构也称云架构]SOA也是分布式应用架构一种。
SOA架构提供配套的服务治理，包括服务注册、服务路由、服务授权、服务降级、服务监控等等。
SOA架构既体现业务的拆分，又体现业务的整合，更多地从业务整体上考虑系统拆分。
优点：以服务层为主，聚焦核心业务，同时以提供整个系统共享，服务作为独立的应用，独立部署，接口清晰，很容易做自动化测试和部署，服务是无状态的，很容易做水平扩展；通过容器虚拟化技术，实现故障隔离和资源高效利用。
缺点：系统依赖复杂，给开发/测试/部署带来不便，分布式数据一致性和分布式事务支持困难，一般通过最终一致性简化解决。
单体式应用系统只有一个应用、打包成一个应用；部署在一台机器；在一个DB里存储数据.单体式应用采用分层架构，一般为表示层、业务层、数据访问层、DB层，表示层负责用户体验，业务层负责业务逻辑，数据访问层负责DB层的数据存取优点：开发、编译、调试一站式、一个应用程序包含所有功能点，容易测试和部署缺点：系统逐渐庞大时，代码复杂度高，难以维护，应用扩展水平低，业务和模块职责区分不清晰。
软件架构软件架构一、微服务架构微服务架构（microservices architecture）是服务导向架构（service-oriented architecture，缩写 SOA）的升级。
每一个服务就是一个独立的部署单元（separately deployedunit）。
软件架构模式：掌握常见的软件架构模式和设计原则
软件架构模式：掌握常见的软件架构模式和设计原则软件架构是软件系统整体结构的框架，负责定义软件系统的各个组成部分之间的关系和交互方式。
在软件开发过程中，选择合适的软件架构模式可以提高软件系统的可维护性、扩展性和性能。
下面我们将介绍一些常见的软件架构模式和设计原则。
1.分层架构模式分层架构模式是将系统分为若干层次，每一层次有各自的功能和责任，各层之间通过明确的接口进行通信。
常见的分层架构包括三层架构和N层架构。
三层架构包括表示层（Presentation Layer）、业务逻辑层（Business Logic Layer）和数据访问层（Data Access Layer），分别负责显示用户界面、处理业务逻辑和与数据存储进行交互。
2. MVC模式MVC（Model-View-Controller）模式是一种将应用程序分为数据模型（Model）、视图（View）和控制器（Controller）三个部分的软件架构模式。
Model负责数据的管理和处理，View负责界面的展示，Controller负责处理用户的输入和决定视图和模型之间的交互。
3.微服务架构微服务架构是一种将一个大型软件系统拆分成多个小型、可独立部署的服务的架构模式。
每个微服务都可以独立开发、部署和运行，各个微服务之间通过API进行通信。
微服务架构可以提高系统的灵活性和可扩展性，有利于团队间的协作和部署的快速迭代。
4.事件驱动架构事件驱动架构是一种基于事件和消息传递的软件架构模式，系统中的各个组件相互之间通过事件的方式进行通信。
当一个组件的状态发生变化时，它会发布一个事件，其他组件可以订阅这个事件并做出相应的响应。
事件驱动架构可以降低系统组件之间的耦合度，提高系统的可扩展性和灵活性。
5.领域驱动设计（DDD）领域驱动设计是一种将软件设计与业务领域相结合的设计方法。
DDD将系统分为领域层、应用层和基础设施层，通过模型驱动的方式建模业务领域，并将业务规则和逻辑体现在软件设计中。
软件公司组织结构
软件公司组织结构：
软件公司的组织结构因公司规模、业务领域和产品类型等因素而有所不同，但通常可以分为以下几种类型：
1.扁平化组织结构：这种组织结构层次较少，信息传递速度快，有利于快速响应市场
变化和客户需求。
通常适用于小型和中型软件公司。
2.矩阵式组织结构：这种组织结构将职能部门和项目部门相结合，既有专业化的分工，
又有项目化的协作。
优点是能够同时处理多个项目，提高资源利用率，但也可能导致管理复杂化。
3.层次化组织结构：这种组织结构层次较多，管理严格，有利于保证公司的稳定性和
秩序性。
但缺点是信息传递速度较慢，对市场变化的响应速度也较慢。
4.网络化组织结构：这种组织结构将公司内部和外部资源进行整合，通过信息技术手
段实现跨地域、跨行业的合作和协同。
优点是能够快速响应市场变化和客户需求，但需要强大的信息技术手段支持。
软件开发中常见的架构模式
软件开发中常见的架构模式软件开发中的架构模式是一种被广泛运用的技术重点。
在现代的软件开发中，应用层（Application Layer）、服务层（Service Layer）、数据访问层（Data Access Layer）是一种常见的架构模式，它们在开发中被广泛应用，并且这些架构模式是十分重要的存在，下面我们将对这些常见的架构模式进行详细的介绍。
一、应用层架构模式应用层架构模式是一种基于MVC（Model-View-Controller）的的开发模式，它被广泛应用于Web开发中。
这种架构模式分为三层，分别为控制层（Controller）、数据层（Model）和视图层（View）。
控制层（Controller）：控制层负责接收用户请求并处理请求，它是整个应用程序的外层核心。
控制层可以调用的业务逻辑层中的方法，也可以根据业务逻辑层返回的结果来更新视图层。
视图层（View）：视图层是控制层提供给用户的界面，它负责显示数据或者接收用户输入。
视图层展示的数据来源于业务逻辑层中的方法返回结果。
数据层（Model）：数据层承载着整个应用程序的数据，包括数据结构、数据交互、数据校验等。
二、服务层架构模式服务层架构模式是一种基于SOA（Service-Oriented Architecture）的开发模式，它应用于企业级应用程序以及大规模软件系统的开发中。
服务层架构模式分为四层，分别为服务层（Service）、应用层（Application）、基础设施层（Infrastructure）、资源层（Resource）。
服务层（Service）：服务层是整个服务层架构模式中的核心，它提供各种服务以满足客户端的需求。
服务层的实现是通过实现SOA 标准的 Web 服务或 RESTful API。
应用层（Application）：应用层聚焦于客户端与服务层之间的数据传输问题，并处理抽象服务层中底层服务的问题。
应用层为客户端提供了友好的调用接口，通过 Service 与 Infrastructure 层之间的交互提供简单易用的 API。
架构模式常见的软件架构设计方案
架构模式常见的软件架构设计方案在软件开发领域，架构模式是一种用于设计和组织软件系统的概念和模板。
它提供了一组固定的模式和指导原则，可以帮助开发人员解决常见的软件架构问题。
本文将介绍几种常见的软件架构设计方案，包括分层架构、微服务架构、容器化架构以及事件驱动架构。
一、分层架构分层架构是一种常见且易于理解的软件架构设计方案。
它将软件系统划分为多个层次，每个层次都有特定的职责和功能。
典型的分层架构包括表示层、业务逻辑层和数据访问层。
表示层负责用户界面的展示和交互，业务逻辑层处理业务规则和逻辑，数据访问层负责与数据库或其他数据源进行通信。
二、微服务架构微服务架构是一种基于小型、独立的服务的架构设计方案。
它倡导将软件系统拆分为一组小型的服务，每个服务都运行在独立的进程中，并通过轻量级的通信机制进行交互。
每个微服务都有自己的数据库和业务逻辑，可以独立进行部署和扩展。
微服务架构提供了高度可伸缩性和灵活性，适用于复杂的大规模系统。
三、容器化架构容器化架构是一种通过使用容器技术来组织和管理软件系统的架构设计方案。
容器是一种轻量级的、可隔离的运行环境，可以包含应用程序及其所有的依赖项。
容器化架构使用容器来打包和部署应用程序，提供了一种便捷的方式来实现环境一致性和快速部署。
常见的容器化技术包括Docker和Kubernetes。
四、事件驱动架构事件驱动架构是一种基于事件和消息传递的架构设计方案。
它将软件系统划分为多个松散耦合的组件，组件之间通过事件和消息进行通信和协作。
当一个组件触发了一个事件，其他订阅该事件的组件可以相应地采取行动。
事件驱动架构可以提供更好的松耦合性和可扩展性，适用于需要处理大量并发事件的系统。
综上所述，分层架构、微服务架构、容器化架构以及事件驱动架构是常见的软件架构设计方案。
每种架构方案都有其独特的优势和适用场景，开发人员可以根据具体的项目需求选择合适的架构模式来设计和组织软件系统。
通过合理选择和应用架构模式，可以提高软件系统的可维护性、可测试性和性能表现，从而满足用户的需求。
软件架构设计：选择合适的架构模式
软件架构设计：选择合适的架构模式在软件开发过程中，选择合适的架构模式对于构建高效、可扩展和可维护的软件系统至关重要。
架构模式是一种在设计阶段用于解决常见问题的通用解决方案，它提供了一种结构化的方法，帮助开发团队组织和管理系统的各个组件。
本文将介绍几种常见的架构模式，并且讨论如何选择合适的架构模式。
首先，我们来介绍一下几种常见的架构模式。
1.分层架构模式：分层架构模式将软件系统划分为多个层次，每个层次负责完成不同的功能。
常见的层次包括表示层、业务逻辑层和数据访问层。
这种模式的优势是各个层次之间的耦合度较低，易于维护和修改。
2. MVC架构模式：MVC是Model-View-Controller的缩写，是一种将软件系统分为三个部分的架构模式。
Model负责处理逻辑和与数据交互，View负责向用户展示数据，Controller负责协调Model和View 之间的通信。
这种架构模式的优势是松散耦合，易于测试和维护。
3.客户端-服务器架构模式：客户端-服务器架构模式是将软件系统分为两个独立的部分，客户端负责与用户进行交互，服务器负责处理业务逻辑和数据存储。
这种模式的优势是可扩展性和灵活性。
4.微服务架构模式：微服务架构模式将一个大型系统拆分成多个小的、独立的服务。
每个服务都有自己的数据库和接口，可以独立部署和扩展。
这种模式的优势是可伸缩性和灵活性。
选择合适的架构模式需要考虑多个因素。
首先，要考虑系统的规模和复杂性。
如果系统较小且功能简单，可以选择简单的架构模式，如分层架构模式。
而对于大型系统或复杂系统，更适合选择更高级的架构模式，如微服务架构模式。
其次，要考虑系统的可维护性和可扩展性。
如果系统需要经常进行修改和扩展，那么选择松散耦合的架构模式，如MVC架构模式或微服务架构模式，可以更方便地进行系统的修改和扩展。
另外，还要考虑团队成员的技术背景和熟悉度。
团队成员对于某种架构模式是否熟悉和了解，以及是否具备相应的技术能力，也是选择合适的架构模式的考虑因素之一。
软件架构设计模式简述
软件架构设计模式简述在软件开发设计中我们经常会面对业务分析，提取领域问题，从而实现软件架构设计。
关于软件架构设计Martin Fowle 概括了四种方式的架构模式。
它们分别为事务性脚本，表驱动模式，活动记录模式，领域驱动设计。
前两者事务性脚本，表驱动模式作为面向过程方式架构设计，后两者为面向对象架构设计。
它们适合于不同的业务场景，它们也各有长短。
事务脚本模式事务脚本模式是架构设计中最简单的架构模式，面向过程模式。
该模式以用户的操作，UI表现为起点，设计业务组件，即业务逻辑将直接映射到用户界面的操作。
这通常是从表现层逻辑出发，表现层需要什么那么业务层就提供什么，直到数据层。
针对每一个用户的新功能都需要新增一个从UI到关系数据库的分支流程。
其适用于逻辑不是很复杂或者变化不会太大的稳定的应用系统开发。
其不需要付出与业务无关的额外代价，并且在现代可见即可得的IDE 结合，能够很快的进行快速应用开发（RAD）。
但是这种优势，也是其最大的劣势，程序中充满了IF-else，switch-case之类的逻辑或者大量的static的方法，每个功能都是一个程序分支，这对代码无法重用。
编码不易于维护，对复杂项目和变化需求不适应。
表驱动模式表驱动模式为每个数据库表定义一个表模块类，包含操作该数据的所有行为方法。
作为一个容器，将数据和行为组织在一起。
其对数据的粒度针对于数据表，而非数据行，因此需要以集合或者表(DataTable)传递数据信息。
表驱动模式基于对象但是完全由数据库驱动开发，在业务模型和数据库关系模型显著差异的情况下，应对需求，并不是那么适合。
但是在.net中提供的一些列如强类型DataSet等IDE的辅助下自动生成大量的代码，也是一个不错的选择，因为部分数据库的操作趋于自动化。
表驱动模式没有太过于关注业务逻辑，而是关注数据库表结构。
而业务逻辑和领域问题才是软件核心，所以对于复杂的场景也存在不能很好的胜任。
活动记录模式活动记录模式是一个以数据库表一行Row为对象，并且对象中包含行为和数据的模式方法。
软件架构模式介绍
软件架构模式介绍随着软件开发的不断发展，软件的规模越来越大，软件开发上也逐步考虑到了系统的架构问题。
所谓软件架构，简单来说就是一个软件系统的总体结构，该结构将软件系统分解成多个部分并规定它们之间的关系。
在这个过程中，我们可以采用各种不同的架构模式，以满足软件的需求和性能要求。
软件架构模式是一些可供选择的方式，它们是既经过实践和验证的又被广泛应用的。
下面我们将介绍一些常见的软件架构模式。
1. 层次结构架构模式层次结构架构是一种将软件系统分为几个层次的架构模式。
每一层实现一些特定的功能，并在下一层上构建。
较低层次上的层次可以调用上层次的层次，但是上层次的层次不能调用下层次的层次。
这种架构模式适用于有明确定义的层次和功能的系统。
这样可以使代码具有可重用性并促进维护。
2. 管道-过滤器架构模式管道-过滤器架构模式是一种将一些处理操作按顺序连接起来的架构模式。
这种模式适用于数据流处理系统，例如数据交换，格式转换和其他一些数据的转换操作。
在管道架构中，处理过程是按照顺序连接的，每个处理过程被称为过滤器，过滤器通常只关心输入数据和输出数据之间的逻辑关系。
3. 客户端-服务器架构模式客户端-服务器架构模式是一种分布式架构，其中客户端应用程序向服务器发送请求，服务器将返回数据或者结果。
这种架构模式适用于需要处理大量数据的系统。
客户端-服务器架构通常包括一个或多个客户端，这些客户端通过网络连接到一台或多台服务器。
客户端向服务器发送请求，服务器响应请求并返回结果或数据。
4. 事件驱动架构模式事件驱动架构模式是一种使用事件来处理业务逻辑的架构模式。
在这种模式中，各个组件通过事件进行通讯和协调。
事件驱动架构的特点是高度可扩展性，因为各个组件都是独立运作的。
在这种模式中，事件通常由各个组件负责生成和处理。
5. 分布式架构模式分布式架构模式是指将一个系统分解成多个部分并在不同的计算机上分布运行的架构模式。
不同的组件使用网络协议进行通信。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件架构之四种类型简介如果一个软件开发人员，不了解软件架构的演进，会制约技术的选型和开发人员的生存、晋升空间。
这里我列举了目前主要的四种软件架构以及他们的优缺点，希望能够帮助软件开发人员拓展知识面。
一、单体架构单体架构比较初级，典型的三级架构，前端(Web/手机端)+中间业务逻辑层+数据库层。
这是一种典型的Java Spring mvc或者Python Django框架的应用。
其架构图如下所示：单体架构单体架构的应用比较容易部署、测试，在项目的初期，单体应用可以很好地运行。
然而，随着需求的不断增加，越来越多的人加入开发团队，代码库也在飞速地膨胀。
慢慢地，单体应用变得越来越臃肿，可维护性、灵活性逐渐降低，维护成本越来越高。
下面是单体架构应用的一些缺点：复杂性高：以一个百万行级别的单体应用为例，整个项目包含的模块非常多、模块的边界模糊、依赖关系不清晰、代码质量参差不齐、混乱地堆砌在一起。
可想而知整个项目非常复杂。
每次修改代码都心惊胆战，甚至添加一个简单的功能，或者修改一个Bug都会带来隐含的缺陷。
技术债务：随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越积越多。
“不坏不修”，这在软件开发中非常常见，在单体应用中这种思想更甚。
已使用的系统设计或代码难以被修改，因为应用程序中的其他模块可能会以意料之外的方式使用它。
部署频率低：随着代码的增多，构建和部署的时间也会增加。
而在单体应用中，每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。
全量部署的方式耗时长、影响范围大、风险高，这使得单体应用项目上线部署的频率较低。
而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复，出错率比较高。
可靠性差：某个应用Bug，例如死循环、内存溢出等，可能会导致整个应用的崩溃。
扩展能力受限：单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。
例如，应用中有的模块是计算密集型的，它需要强劲的CPU；有的模块则是IO密集型的，需要更大的内存。
由于这些模块部署在一起，不得不在硬件的选择上做出妥协。
阻碍技术创新：单体应用往往使用统一的技术平台或方案解决所有的问题，团队中的每个成员都必须使用相同的开发语言和框架，要想引入新框架或新技术平台会非常困难。
二、分布式应用中级架构，分布式应用，中间层分布式+数据库分布式，是单体架构的并发扩展，将一个大的系统划分为多个业务模块，业务模块分别部署在不同的服务器上，各个业务模块之间通过接口进行数据交互。
数据库也大量采用分布式数据库，如redis、ES、solor等。
通过LVS/Nginx代理应用，将用户请求均衡的负载到不同的服务器上。
其架构图如下所示：分布式架构该架构相对于单体架构来说，这种架构提供了负载均衡的能力，大大提高了系统负载能力，解决了网站高并发的需求。
另外还有以下特点：降低了耦合度：把模块拆分,使用接口通信,降低模块之间的耦合度。
责任清晰：把项目拆分成若干个子项目,不同的团队负责不同的子项目。
扩展方便：增加功能时只需要再增加一个子项目,调用其他系统的接口就可以。
部署方便:可以灵活的进行分布式部署。
提高代码的复用性：比如service层,如果不采用分布式rest服务方式架构就会在手机wap商城,微信商城,pc,android，ios每个端都要写一个service层逻辑,开发量大,难以维护一起升级,这时候就可以采用分布式rest服务方式,公用一个service层。
缺点 : 系统之间的交互要使用远程通信,接口开发增大工作量,但是利大于弊。
三、微服务架构微服务架构，主要是中间层分解，将系统拆分成很多小应用（微服务），微服务可以部署在不同的服务器上，也可以部署在相同的服务器不同的容器上。
当应用的故障不会影响到其他应用，单应用的负载也不会影响到其他应用，其代表框架有Spring cloud、Dubbo等。
其架构图如下所示：微服务架构易于开发和维护：一个微服务只会关注一个特定的业务功能，所以它业务清晰、代码量较少。
开发和维护单个微服务相对简单。
而整个应用是由若干个微服务构建而成的，所以整个应用也会被维持在一个可控状态。
单个微服务启动较快：单个微服务代码量较少，所以启动会比较快。
局部修改容易部署：单体应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题。
一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。
技术栈不受限：在微服务架构中，可以结合项目业务及团队的特点，合理地选择技术栈。
例如某些服务可使用关系型数据库MySQL；某些微服务有图形计算的需求，可以使用Neo4j；甚至可根据需要，部分微服务使用Java 开发，部分微服务使用Node.js开发。
微服务虽然有很多吸引人的地方，但它并不是免费的午餐，使用它是有代价的。
使用微服务架构面临的挑战。
运维要求较高：更多的服务意味着更多的运维投入。
在单体架构中，只需要保证一个应用的正常运行。
而在微服务中，需要保证几十甚至几百个服务服务的正常运行与协作，这给运维带来了很大的挑战。
分布式固有的复杂性：使用微服务构建的是分布式系统。
对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的挑战。
接口调整成本高：微服务之间通过接口进行通信。
如果修改某一个微服务的API，可能所有使用了该接口的微服务都需要做调整。
重复劳动：很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，从而导致代码重复。
尽管可以使用共享库来解决这个问题（例如可以将这个功能封装成公共组件，需要该功能的微服务引用该组件），但共享库在多语言环境下就不一定行得通了。
四、Serverless架构当我们还在容器的浪潮中前行时，已经有一些革命先驱悄然布局另外一个云计算战场：Serverless架构。
Serverless架构2014年11月14日，亚马逊AWS发布了新产品Lambda。
当时Lambda 被描述为：一种计算服务，根据时间运行用户的代码，无需关心底层的计算资源。
从某种意义上来说，Lambda姗姗来迟，它像云计算的PaaS理念：客户只管业务，无需担心存储和计算资源。
在此前不久，2014年10月22日，谷歌收购了实时后端数据库创业公司Firebase。
Firebase声称开发者只需引用一个API库文件就可以使用标准REST API的各种接口对数据进行读写操作，只需编写HTML＋CSS＋JavaScrip前端代码，不需要服务器端代码（如需整合，也极其简单）。
相对于上两者，Facebook 在2014年二月收购的Parse，则侧重于提供一个通用的后台服务。
这些服务被称为Serverless或no sever。
想到PaaS （平台即服务）了是吗？很像，用户不需要关心基础设施，只需要关心业务，这是迟到的PaaS，也是更实用的PaaS。
这很有可能将会变革整个开发过程和传统的应用生命周期，一旦开发者们习惯了这种全自动的云上资源的创建和分配，或许就再也回不到那些需要微应用配置资源的时代里去了。
Serverless架构能够让开发者在构建应用的过程中无需关注计算资源的获取和运维，由平台来按需分配计算资源并保证应用执行的SLA（服务等级协议），按照调用次数进行计费，有效的节省应用成本。
ServerLess的架构如上图所示。
其优点如下所示：低运营成本：在业务突发性极高的场景下，系统为了应对业务高峰，必须构建能够应对峰值需求的系统，这个系统在大部分时间是空闲的，这就导致了严重的资源浪费和成本上升。
在微服务架构中，服务需要一直运行，实际上在高负载情况下每个服务都不止一个实例，这样才能完成高可用性；在Serverless架构下，服务将根据用户的调用次数进行计费，按照云计算pay-as-you-go原则，如果没有东西运行，你就不必付款，节省了使用成本。
同时，用户能够通过共享网络、硬盘、CPU等计算资源，在业务高峰期通过弹性扩容方式有效的应对业务峰值，在业务波谷期将资源分享给其他用户，有效的节约了成本。
简化设备运维：在原有的IT体系中，开发团队即需要维护应用程序，同时还要维护硬件基础设施；Serverless架构中，开发人员面对的将是第三方开发或自定义的API 和URL，底层硬件对于开发人员透明化了，技术团队无需再关注运维工作，能够更加专注于应用系统开发。
提升可维护性：Serverless架构中，应用程序将调用多种第三方功能服务，组成最终的应用逻辑。
目前，例如登陆鉴权服务，云数据库服务等第三方服务在安全性、可用性、性能方面都进行了大量优化，开发团队直接集成第三方的服务，能够有效的降低开发成本，同时使得应用的运维过程变得更加清晰，有效的提升了应用的可维护性。
更快的开发速度：这一点在现在互联网创业公司得到很好的体现，创业公司往往开始由于人员和资金等问题，不可能每个产品线都同时进行，这时候就可以考虑第三方的Baas平台，比如使用微信的用户认证、阿里云提供的RDS，极光的消息推送，第三方支付及地理位置等等，能够很快进行产品开发的速度，把工作重点放在业务实现上，把产品更快的推向市场。
但ServerLess架构也有其缺点：厂商平台绑定：平台会提供Serverless架构给大玩家，比如AWS Lambda，运行它需要使用AWS指定的服务，比如API网关，DynamoDB，S3等等，一旦你在这些服务上开发一个复杂系统，你会粘牢AWS，以后只好任由他们涨价定价或者下架等操作，个性化需求很难满足，不能进行随意的迁移或者迁移的成本比较大，同时不可避免带来一些损失。
Baas行业内一个比较典型的事件，2016年1月19日Facebook关闭曾经花巨额资金收购的Parse，造成用户不得不迁移在这个平台中产生一年多的数据，无疑需要花费比较大的人力和时间成本。
成功案例比较少，没有行业标准：目前的情况也只适合简单的应用开发，缺乏大型成功案例的推动。
对于Serverless缺乏统一的认知以及相应的标准，无法适应所有的云平台。
目前微服务架构在四种架构中处于主流地位，很多应用第一、第二种架构的企业也开始慢慢转向微服务架构。
到目前为止微服务的技术相对于二三年前已经比较成熟，第四种架构将是未来发展的一种趋势。