关于前端:四种软件架构演进史程序员会一种就很牛了

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

一、单体架构

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

单体架构

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

上面是单体架构利用的一些毛病：

• 复杂性高：以一个百万行级别的单体利用为例，整个我的项目蕴含的模块十分多、模块的边界含糊、依赖关系不清晰、代码品质参差不齐、凌乱地堆砌在一起。可想而知整个我的项目非常复杂。每次批改代码都大惊失色，甚至增加一个简略的性能，或者批改一个 Bug 都会带来隐含的缺点。
• 技术债权：随着时间推移、需要变更和人员更迭，会逐步造成应用程序的技术债权，并且越积 越多。“不坏不修”，这在软件开发中十分常见，在单体利用中这种思维更甚。已应用的零碎设计或代码难以被批改，因为应用程序中的其余模块可能会以意料之外的形式应用它。
• 部署频率低：随着代码的增多，构建和部署的工夫也会减少。而在单体利用中，每次性能的变更或缺点的修复都会导致须要重新部署整个利用。全量部署的形式耗时长、影响范畴大、危险高，这使得单体利用我的项目上线部署的频率较低。而部署频率低又导致两次公布之间会有大量的性能变更和缺点修复，出错率比拟高。
• 可靠性差：某个利用 Bug，例如死循环、内存溢出等，可能会导致整个利用的解体。
• 扩大能力受限：单体利用只能作为一个整体进行扩大，无奈依据业务模块的须要进行伸缩。例如，利用中有的模块是计算密集型的，它须要强劲的 CPU；有的模块则是 IO 密集型的，须要更大的内存。因为这些模块部署在一起，不得不在硬件的抉择上做出斗争。
• 妨碍技术创新：单体利用往往应用对立的技术平台或计划解决所有的问题，团队中的每个成员 都必须应用雷同的开发语言和框架，要想引入新框架或新技术平台会十分艰难。

二、分布式应用

1. 大型互联网架构演进过程
2. 架构师应具备的分布式常识
3. 支流分布式架构设计详解

中级架构，分布式应用，中间层分布式 + 数据库分布式，是单体架构的并发扩大，将一个大的零碎划分为多个业务模块，业务模块别离部署在不同的服务器上，各个业务模块之间通过接口进行数据交互。数据库也大量采纳分布式数据库，如 redis、ES、solor 等。通过 LVS/Nginx 代理利用，将用户申请平衡的负载到不同的服务器上。其架构图如下所示：

分布式架构

该架构绝对于单体架构来说，这种架构提供了负载平衡的能力，大大提高了零碎负载能力，解决了网站高并发的需要。另外还有以下特点：

1. 升高了耦合度：把模块拆分, 应用接口通信, 升高模块之间的耦合度。
2. 责任清晰：把我的项目拆分成若干个子项目, 不同的团队负责不同的子项目。
3. 扩大不便：减少性能时只须要再减少一个子项目, 调用其余零碎的接口就能够。
4. 部署不便: 能够灵便的进行分布式部署。
5. 进步代码的复用性：比方 service 层, 如果不采纳分布式 rest 服务形式架构就会在手机 wap 商城, 微信商城,pc,android，ios 每个端都要写一个 service 层逻辑, 开发量大, 难以保护一起降级, 这时候就能够采纳分布式 rest 服务形式, 专用一个 service 层。

毛病 : 零碎之间的交互要应用近程通信, 接口开发增大工作量, 然而利大于弊。

三、微服务架构

======================================

1. 服务的前世今生
2. 基于分布式思维下的 RPC 解决方案
3. Dubbo 利用及源码解读
4. SpringBoot
5. SpringCloud 利用及源码解读
6. Docker 虚拟化技术

微服务架构，次要是中间层合成，将零碎拆分成很多小利用（微服务），微服务能够部署在不同的服务器上，也能够部署在雷同的服务器不同的容器上。当利用的故障不会影响到其余利用，单利用的负载也不会影响到其余利用，其代表框架有 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。这很有可能将会改革整个开发过程和传统的利用生命周期，一旦开发者们习惯了这种全自动的云上资源的创立和调配，或者就再也回不到那些须要微利用配置资源的时代里去了。