如果一个软件开发者不了解软件架构的演进，就会制约技术的选择和开发者的生存和晋升空间。这里我列出了四种主要的软件架构及其优缺点，希望能帮助软件开发者扩充知识面。1、单体架构单体架构比较初级，典型的三层架构，前端（Web/移动端）+中间业务逻辑层+数据库层。这是典型的JavaSpringmvc或PythonDrango框架应用程序。其架构图如下：单体架构单体应用更易于部署和测试。在项目的初始阶段，单体应用可以很好地运行。但是，随着需求不断增加，越来越多的人加入开发团队，代码库也迅速膨胀。慢慢地，单体应用越来越臃肿，可维护性和灵活性逐渐下降，维护成本越来越高。以下是单体架构应用的一些缺点：复杂度高：以一个百万行级别的单体应用为例，整个项目包含了很多模块，模块边界模糊，依赖不明确，代码质量参差不齐，乱七八糟地堆在一起。可以想象整个工程非常复杂。每次修改代码，我都感到毛骨悚然。即使增加一个简单的功能或修改一个bug也会带来隐藏的缺陷。技术债务：随着时间的推移，随着需求的变化和人员的变化，应用程序的技术债务会累积起来。“Ifitdoesn'tbreak,don'tfixit”，这种思想在软件开发中很普遍，在单体应用中更是如此。使用过的系统设计或代码很难修改，因为应用程序中的其他模块可能会以意想不到的方式使用它。低部署频率：随着代码的增长，构建和部署时间也会增加。在单体应用程序中，每个功能更改或缺陷修复都将导致需要重新部署整个应用程序。全量部署方式耗时长、影响范围大、风险高，使得单体应用项目上线部署频率较低。部署频率低导致两次发布之间有大量的功能变更和缺陷修复，错误率比较高。可靠性差：一个应用程序的bug，比如死循环、内存溢出等，都可能导致整个应用程序崩溃。可扩展性有限：单个应用只能作为一个整体进行扩展，不能根据业务模块的需要进行扩展。例如，应用程序中的某些模块是计算密集型的，需要强大的CPU；有些模块是IO密集型的，需要更大的内存。由于这些模块一起部署，因此必须在硬件选择上做出妥协。技术创新的障碍：单体应用往往使用统一的技术平台或解决方案来解决所有问题。团队的每个成员都必须使用相同的开发语言和框架。引入新框架或新技术平台将非常困难。2.分布式应用中间架构，分布式应用，中间层分布式+数据库分布式，是单体架构的并发扩展，将一个大的系统划分为多个业务模块，业务模块部署在不同的服务器上，各个之间进行数据交互业务模块通过接口。数据库也大量采用分布式数据库，如redis、ES、solor等，通过LVS/Nginx代理应用，将用户请求的负载均衡到不同的服务器上。其架构图如下：分布式架构与单体架构相比，该架构提供了负载均衡能力，大大提高了系统的负载能力，解决了网站的高并发需求。此外，还有以下特点：降低耦合：将模块拆分，使用接口进行通信，降低模块之间的耦合度。职责清晰：将项目拆分成多个子项目，不同的团队负责不同的子项目。易于扩展：增加功能时，只需再增加一个子项，调用其他系统的接口即可。部署方便：分布式部署灵活。提高代码复用性：比如在服务层，如果不使用分布式rest服务架构，则必须在手机wap商城、微信商城、PC、Android、ios端各写一个服务层逻辑，开发量大。很难一起维护和升级。这时可以采用分布式rest服务的方式，共享一个服务层。缺点：系统间交互需要远程通信，接口开发增加工作量，但利大于弊。3、微服务架构微服务架构主要是中间层的分解，将系统拆分成很多小的应用（微服务）。微服务可以部署在不同的服务器上，也可以部署在同一台服务器上的不同容器中。当应用程序失败时不会影响其他应用程序，单个应用程序的负载不会影响其他应用程序。代表框架有Springcloud、Dubbo等，其架构图如下：微服务架构易于开发和维护：一个微服务只关注特定的业务功能，业务清晰，代码量小。开发和维护单个微服务相对简单。整个应用是由几个微服务构建而成的，所以整个应用会保持在一个可控的状态。单个微服务启动速度更快：单个微服务的代码更少，因此启动速度会更快。本地修改部署方便：只要修改单个应用，整个应用都要重新部署。微服务解决了这个问题。一般来说，修改一个微服务，只需要重新部署服务即可。不受限制的技术栈：在微服务架构中，可以根据项目业务和团队的特点，合理选择技术栈。比如一些服务可以使用关系型数据库MySQL；一些微服务可以使用Neo4j来满足图形计算需求；有些微服务可以用Java开发，有些微服务可以用Node.js开发。虽然微服务有很大的吸引力，但它不是免费的午餐，使用它是有代价的。使用微服务架构的挑战。更高的运维要求：更多的业务意味着更多的运维投入。在单体架构中，只需要保证一个应用程序正常运行。在微服务中，需要保证几十个甚至上百个服务的正常运行和协同，这给运维带来了很大的挑战。分布式的内在复杂性：你用微服务构建的是一个分布式系统。对于分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的挑战。接口调整成本高：微服务通过接口进行通信。如果修改了某个微服务的API，可能所有使用该接口的微服务都需要调整。重复劳动：很多服务可能使用同一个功能，但是这个功能还没有被分解成一个微服务。这时候每个服务都可能开发这个功能，造成代码重复。虽然可以使用共享库来解决这个问题（比如可以把这个功能封装成一个公共组件，供需要这个功能的微服务引用），但是共享库不一定能在多语言环境下工作。4、Serverless架构当我们还在容器的浪潮中前行时，一些革命先行者已经悄然布局了另一个云计算战场：Serverless架构。Serverless架构2014年11月14日，亚马逊AWS发布了新产品Lambda。当时，Lambda被描述为：一种不关心底层计算资源，按时间运行用户代码的计算服务。从某种意义上说，Lambda早就应该出现了。就像云计算的PaaS理念：客户只需要专注于业务，无需担心存储和计算资源。在此之前不久，2014年10月22日，谷歌收购了实时后端数据库初创公司Firebase。Firebase声称开发者只需要引用一个API库文件就可以使用标准RESTAPI的各种接口读写数据，只需要编写HTML+CSS+JavaScript前端代码，不需要服务端代码（如果需要集成，也非常简单）。与上述两者相比，Facebook于2014年2月收购的Parse专注于提供通用的后台服务。这些服务称为无服务器或无服务器。您是否想到过PaaS（平台即服务）？很像，用户不需要关心基础设施，只需要关心业务。这是一个后期的PaaS，也是一个更实用的PaaS。这很有可能改变整个开发过程和传统的应用程序生命周期。一旦开发者习惯了这种在云端全自动创建和分配资源的方式，他们可能就再也不会回到那些需要微应用来配置资源的方式了。时代已经过去了。Serverless架构让开发者无需关注计算资源的获取和运维即可构建应用。平台按需分配计算资源，保证应用执行的SLA（服务水平协议）。按通话次数计费，有效。节省申请费用。ServerLess的架构如上图所示。其优势如下：运营成本低：在业务突发性极高的场景下，系统必须构建能够应对高峰需求的系统，才能应对高峰需求。该系统大部分时间处于闲置状态，导致资源严重浪费，成本上升。在微服务架构中，服务需要一直处于运行状态。实际上，在高负载情况下，每个服务都有多个实例，从而达到高可用；计算按量付费原则，如果没有运行，则无需付费，节省使用成本。同时，用户可以通过共享网络、硬盘、CPU等计算资源，在业务高峰期通过弹性扩展有效应对业务高峰，在业务低谷期与其他用户共享资源，有效节约成本。简化设备运维：在原有的IT系统中，开发团队既需要维护应用程序，也需要维护硬件基础设施；在Serverless架构中，开发者将面对第三方开发或定制的API和URL。底层硬件对开发者透明，技术团队无需再关注运维工作，可以更专注于应用系统开发。提高可维护性：在Serverless架构中，应用会调用各种第三方功能服务，形成最终的应用逻辑。目前，登录认证服务、云数据库服务等第三方服务在安全性、易用性、性能等方面都得到了极大的优化。开发团队直接集成第三方服务，可以有效降低开发成本，让应用的运维流程变得更加清晰，有效提升应用的可维护性。更快的发展速度：这一点在互联网创业公司身上体现得很好。创业公司往往在人员、资金等问题上起步，不可能同时开展各个产品线。这时候可以考虑第三方BaaS平台，比如利用微信的用户认证、阿里云提供的RDS、极光的消息推送、第三方支付和地理位置等，可以快速开发产品，专注业务实施，并使产品更快地推向市场。但是ServerLess架构也有缺点：厂商平台绑定：平台会提供一个serverless架构给大玩家，比如AWSLambda，需要使用AWS指定的服务，比如API网关，DynamoDB，S3等，一旦你在这些服务上开发了一个复杂的系统，你就会死守AWS，以后就不得不让他们涨价或者下架了。难以满足个性化需求，不能随意迁移或迁移成本较高。同时，也难免会带来一些损失。Baas行业的一个典型事件，2016年1月19日，Facebook关闭了花费巨资收购的Parse，导致用户不得不迁移这个平台产生的数据长达一年多，这无疑需要大量的人力和时间成本。成功案例相对较少，没有行业标准：现状只适合简单的应用开发，缺乏大规模成功案例的推动。Serverless缺乏统一的认识和相应的标准，不能适应所有的云平台。目前微服务架构在四种架构中处于主流，很多应用第一、二种架构的企业也开始慢慢转向微服务架构。到目前为止，微服务的技术相比两三年前已经比较成熟，第四种架构将是未来发展的一个趋势。如果喜欢我的文章，请关注我的简书。教你使用springcloud和docker轻松愉快的搭建微服务。
