起源：jianshu.com/p/e7b992a82dc0

如果一个软件开发人员，不理解软件架构的演进，会制约技术的选型和开发人员的生存、降职空间。这里我列举了目前次要的四种软件架构以及他们的优缺点，心愿可能帮忙软件开发人员拓展知识面。

一、单体架构

单体架构比拟高级，典型的三级架构，前端 (Web/ 手机端)+ 中间业务逻辑层 + 数据库层。这是一种典型的 Java Spring mvc 或者 Python Drango 框架的利用。其架构图如下所示：

单体架构

单体架构的利用比拟容易部署、测试，在我的项目的初期，单体利用能够很好地运行。然而，随着需要的一直减少，越来越多的人退出开发团队，代码库也在飞速地收缩。缓缓地，单体利用变得越来越臃肿，可维护性、灵活性逐步升高，保护老本越来越高。上面是单体架构利用的一些毛病：

复杂性高 ：以一个百万行级别的单体利用为例，整个我的项目蕴含的模块十分多、模块的边界含糊、依赖关系不清晰、代码品质参差不齐、凌乱地堆砌在一起。可想而知整个我的项目非常复杂。每次批改代码都大惊失色，甚至增加一个简略的性能，或者批改一个 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 不足对立的认知以及相应的规范，无奈适应所有的云平台。

目前微服务架构在四种架构中处于支流位置，很多利用第一、第二种架构的企业也开始缓缓转向微服务架构。到目前为止微服务的技术绝对于二三年前曾经比拟成熟，第四种架构将是将来倒退的一种趋势。