最常⽤的4⼤软件架构
如果⼀个软件开发⼈员，不了解软件架构的演进，会制约技术的选型和开发⼈员的⽣存、晋升空间。这⾥我列举了⽬前主要的四种软件架构以及他们的优缺点，希望能够帮助软件开发⼈员拓展知识⾯。
⼀、单体架构
单体架构⽐较初级，典型的三级架构，前端(Web/⼿机端)+中间业务逻辑层+数据库层。这是⼀种典型的Java Spring mvc或者Python Drango框架的应⽤。其架构图如下所⽰：
单体架构
分布式和微服务的关系单体架构的应⽤⽐较容易部署、测试， 在项⽬的初期，单体应⽤可以很好地运⾏。然⽽，随着需求的不断增加， 越来越多的⼈加⼊开发团队，代码库也在飞速地膨胀。慢慢地，单体应⽤变得越来越臃肿，可维护性、灵活性逐渐降低，维护成本越来越⾼。下⾯是单体架构应⽤的⼀些缺点：
复杂性⾼：以⼀个百万⾏级别的单体应⽤为例，整个项⽬包含的模块⾮常多、模块的边界模糊、 依赖关系不清晰、 代码质量参差不齐、 混乱地堆砌在⼀起。可想⽽知整个项⽬⾮常复杂。每次修改代码都⼼惊胆战， 甚⾄添加⼀个简单的功能， 或者修改⼀个Bug都会带来隐含的缺陷。
技术债务：随着时间推移、需求变更和⼈员更迭，会逐渐形成应⽤程序的技术债务， 并且越积 越多。“ 不坏不修”， 这在软件开发中⾮常常见， 在单体应⽤中这种思想更甚。已使⽤的系统设计或代码难以被修改，因为应⽤程序中的其他模块可能会以意料之外的⽅式使⽤它。
部署频率低：随着代码的增多，构建和部署的时间也会增加。⽽在单体应⽤中， 每次功能的变更或缺陷的修复都会导致需要重新部署整个应⽤。全量部署的⽅式耗时长、 影响范围⼤、 风险⾼， 这使得单体应⽤项⽬上线部署的频率较低。⽽部署频率低⼜导致两次发布之间会有⼤量的功能变更和缺陷修复，出错率⽐较⾼。
可靠性差：某个应⽤Bug，例如死循环、内存溢出等， 可能会导致整个应⽤的崩溃。
扩展能⼒受限：单体应⽤只能作为⼀个整体进⾏扩展，⽆法根据业务模块的需要进⾏伸缩。例如，应⽤中有的模块是计算密集型的，它需要强劲的CPU；有的模块则是IO密集型的，需要更⼤的内存。由于这些模块部署在⼀起，不得不在硬件的选择上做出妥协。
阻碍技术创新：单体应⽤往往使⽤统⼀的技术平台或⽅案解决所有的问题， 团队中的每个成员 都必须使⽤相同的开发语⾔和框架，要想引⼊新框架或新技术平台会⾮常困难。
⼆、分布式应⽤
中级架构，分布式应⽤，中间层分布式+数据库分布式，是单体架构的并发扩展，将⼀个⼤的系统划分为多个业务模块，业务模块分别部署在不同的服务器上，各个业务模块之间通过接⼝进⾏数据交互。
数据库也⼤量采⽤分布式数据库，如redis、ES、solor等。通过LVS/Nginx代理应⽤，将⽤户请求均衡的负载到不同的服务器上。其架构图如下所⽰：
分布式架构
该架构相对于单体架构来说，这种架构提供了负载均衡的能⼒，⼤⼤提⾼了系统负载能⼒，解决了⽹站⾼并发的需求。
另外还有以下特点：
降低了耦合度：把模块拆分，使⽤接⼝通信，降低模块之间的耦合度。
责任清晰：把项⽬拆分成若⼲个⼦项⽬，不同的团队负责不同的⼦项⽬。
扩展⽅便：增加功能时只需要再增加⼀个⼦项⽬，调⽤其他系统的接⼝就可以。
部署⽅便：可以灵活的进⾏分布式部署。
提⾼代码的复⽤性：⽐如service层，如果不采⽤分布式rest服务⽅式架构就会在⼿机wap商城，商城,pc,android，ios每个端都要写⼀个service层逻辑，开发量⼤，难以维护⼀起升级，这时候就可以采⽤分布式rest服务⽅式，公⽤⼀个service层。
缺点 : 系统之间的交互要使⽤远程通信，接⼝开发增⼤⼯作量，但是利⼤于弊。
另外，关注Java技术栈，在后台回复：⾯试，可以获取我整理的 Java 分布式系列⾯试题和答案，⾮常齐全。
三、微服务架构
微服务架构，主要是中间层分解，将系统拆分成很多⼩应⽤（微服务），微服务可以部署在不同的服务器上，也可以部署在相同的服务器不同的容器上。当应⽤的故障不会影响到其他应⽤，单应⽤的负载也不会影响到其他应⽤，其代表框架有Spring cloud、Dubbo等。
其架构图如下所⽰：
微服务架构
易于开发和维护：⼀个微服务只会关注⼀个特定的业务功能，所以它业务清晰、代码量较少。开发和维护单个微服务相对简单。⽽整个应⽤是由若⼲个微服务构建⽽成的，所以整个应⽤也会被维持在⼀个可控状态。
单个微服务启动较快：单个微服务代码量较少， 所以启动会⽐较快。
局部修改容易部署：单体应⽤只要有修改，就得重新部署整个应⽤，微服务解决了这样的问题。⼀般来说，对某个微服务进⾏修改，只需要重新部署这个服务即可。
技术栈不受限：在微服务架构中，可以结合项⽬业务及团队的特点，合理地选择技术栈。例如某些服务可使⽤关系型数据库MySQL；某些微服务有图形计算的需求，可以使⽤Neo4j；甚⾄可根据需要，部分微服务使⽤Java开发，部分微服务使⽤Node.js开发。
微服务虽然有很多吸引⼈的地⽅，但它并不是免费的午餐，使⽤它是有代价的。使⽤微服务架构⾯临的挑战。
运维要求较⾼：更多的服务意味着更多的运维投⼊。在单体架构中，只需要保证⼀个应⽤的正常运⾏。⽽在微服务中，需要保证⼏⼗甚⾄⼏百个服务服务的正常运⾏与协作，这给运维带来了很⼤的挑战。
分布式固有的复杂性：使⽤微服务构建的是分布式系统。对于⼀个分布式系统，系统容错、⽹络延迟、分布式事务等都会带来巨⼤的挑战。
接⼝调整成本⾼：微服务之间通过接⼝进⾏通信。如果修改某⼀个微服务的API，可能所有使⽤了该接⼝的微服务都需要做调整。
重复劳动：很多服务可能都会使⽤到相同的功能，⽽这个功能并没有达到分解为⼀个微服务的程度，这个时候，可能各个服务都会开发这⼀功能，从⽽导致代码重复。尽管可以使⽤共享库来解决这个问题（例如可以将这个功能封装成公共组件，需要该功能的微服务引⽤该组件），但共享库在多语⾔环境下就不⼀定⾏得通了。
另外，关注Java技术栈，在后台回复：⾯试，可以获取我整理的 Java 分布式、微服务系列⾯试题和答案，⾮常齐全。
四、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缺乏统⼀的认知以及相应的标准，⽆法适应所有的云平台。
⽬前微服务架构在四种架构中处于主流地位，很多应⽤第⼀、第⼆种架构的企业也开始慢慢转向微服务架构。到⽬前为⽌微服务的技术相对于⼆三年前已经⽐较成熟，第四种架构将是未来发展的⼀种趋势。
参考：