软件架构

软件架构就是软件的基本结构，合适的架构是软件成功的最重要因素之一。这里列举了目前流行的4种软件架构。

单体架构

典型的三级架构：前端（web/手机端）+ 中间业务逻辑层 + 数据库。

这是典型的Java Spring MVC 或者Python Django框架的应用。

单体架构应用容易部署测试，但是随着需求不断增加，会变得十分臃肿，可维护性、灵活性会逐渐降低。
复杂性高：一个百万行级别的单体应用，整个项目包含的模块非常多，模块之间的边界、依赖关系容易模糊。可能添加一个简单功能都会带来隐藏的BUG
技术债务：随着时间推移、需求变更和人员更迭，会逐渐形成技术债务，已经使用的系统设计或代码难以被修改，因为应用程序种的其他模块可能会以意料之外的方式使用它
部署频率低：每次功能的变更或者缺陷的修复都会导致重新部署整个应用。全量部署的方式耗时长、影响范围大、风险高，这使得单体应用项目上线部署的频率较低。部署频率低又会导致两次发布之间会有大量的功能变更和缺陷修复，出错率比较高
可靠性差：某个应用BUG，如死循环、内存泄露，可能会导致整个应用崩溃
扩展能力受限：单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。应用中有的模块是计算密集型，需要强劲的CPU；有的模块是IO密集型，需要更多的IO资源以及内存。这些模块部署在一起的话，不得不在硬件上做出妥协
阻碍技术创新：单体应用往往使用统一的技术平台和方案，使用相同的开发语言和框架，想要引入新框架或技术平台较难

分布式应用

中级架构，具有中间层分布式 + 数据库分布式，是单体架构的并发扩展，将一个大的系统划分为多个业务模块，然后分别部署在不同的服务器上，各个业务模块之间通过接口进行数据交互。数据库也采用分布式数据库，通过Nginx代理应用，将用户请求均衡地负载到不同地服务器上。

这种架构提供了负载均衡的能力，大大提高了系统的负载能力，解决了网站高并发的需求，另外还有以下特点：
解耦：模块炒粉，使用接口通信，降低了模块之间的耦合度
责任清晰：拆解为若干个子项目，不同的团队负责不同的子项目
扩展方便：增加功能时只需要增加一个子项目，调用其他系统的接口就可以
部署方便：分布式部署
提高代码复用性：比如service层，如果不采用分布式服务方式架构，就会在pc、android、ios每个端都要写一个service层逻辑，开发量大，难以维护一起升级，此时可以用分布式rest服务方式，共用一个service层
缺点就是系统之间的交互要使用远程通信，接口发开增大工作量，但是利大于弊端

微服务架构

微服务架构主要是中间层分解，将系统拆分成很多小应用（微服务），微服务可以部署在不同的服务器上，也可以部署在相同的服务器的不同容器上。但应用的故障不会影响到其他应用，单应用的负载也不会影响到其他应用，代表框架Spring cloud、Dubbo。
微服务有以下特点：

易于开发和维护：一个微服务只会关注一个特定的业务功能，所以业务清晰、代码量较少。开发和维护单个微服务比较简单。
单个微服务启动较快：单个微服务代码量少，所以启动快
局部修改容易部署：单体应用只要有修改就得重新部署整个应用，而某个微服务修改只需要重新部署整个服务即可
技术栈不受限制
使用微服务也是有代价的：
运维要求高：更多的服务意味着更多的运维投入，微服务中需要保证几十个几百个服务的正常运行和协作
分布式固有的复杂性：微服务构建的仍然是分布式系统，系统容错、网络延迟、分布式事务也比较头疼
接口调整成本高：微服务之间通过接口进行通信，如果修改某一个微服务的API，那么所有使用该接口的微服务都需要进行调整
重复劳动：很多服务可能都会使用到相同的功能，但是这个功能并没有达到分解为一个微服务的程度，所以各个服务都会开发这个功能，从而导致代码重复。尽管可以使用共享库，但是共享库在多语言环境下不一定能用

Serverless架构

Serverless架构能够让开发者在构建应用的过程中无需关注计算资源的获取和运维，由平台来按需分配计算资源并保证应用执行的SLA（服务等级协议），按照调用次数进行计费，有效的节省应用成本。这有点像PaaS（平台便是服务）用户不需要关心基础设施，只需要关心业务，全自动云上资源创建和分配。

这种架构的优点如下：
低运营成本：在业务突发性极高的场景下，系统为了应对业务高峰，必须构建出能够应对峰值需求的系统，这种系统大部分时间是空闲的，这就导致了严重的资源浪费和成本上升。在微服务架构中，服务需要一直运行，在高负载情况下的每个服务都不止一个实例，这样才能完成高可用性。Serverless架构下，服务将根据用户的调用次数进行付费，如果没有东西运行，就不必付费。同时用户可以通过共享网络、硬盘、CPU等计算资源，在业务高峰通过弹性扩容方式有效应对业务峰值，在业务波谷期间将资源分享给其他用户，节约成本
简化设备运维原有的IT体系中，开发团队需要维护程序，也需要维护硬件基础设施。在此架构中，开发人员面对的是第三方的API和URL，底层硬件对于开发人员透明化。
提高可维护性：应用程序将调用多种第三方功能服务，组成最终的应用逻辑。目前的登录鉴权服务、云数据库服务等第三方服务在安全性、可用性、性能上都进行了大量优化，开发团队直接集成第三方服务，能够有效的降低开发成本

总结

目前微服务架构在四种架构中处于主流地位，很多应用第一、第二种架构的企业也开始慢慢转向微服务架构。第四种则是未来发展趋势

Reference

单体→分布式→微服务，这些年的软件架构是怎么发育的？