项目开发软件架构选择指南

标签：指南 服务 单体 开发 软件架构 模块 架构 ESB

从系统的组织和部署结构方面来看，软件架构的演化进程显然有着从简单到复杂的趋势。那是否最新最复杂的架构就是目前业界选择的最佳架构呢？非也。没有最好的架构，只有最合适的架构。在软件架构的选择上，“合适”比“新”更加重要。

对于整个软件架构发展进程，我们可以大致分为三大阶段：单体架构、SOA架构、微服务架构。今天就来简单分析一下架构的发展与优劣势，希望能对大家的项目开发有所助益。

（1）单体架构

单体架构就是把所有的业务逻辑和控制逻辑全部都放在了一起，一个程序里包括了所有的相关功能。（All in one）。比如一个 ERP 系统中包括了商品模块，订单模块，销售模块，库存模块，报表统计等等。

 

 

单体架构基本解决了所有简单的问题，由于开发时所有业务代码都在一起，测试的时候不需要联调各种服务，发布维护非常轻松。

但缺点也很明显，每次修改代码都心惊胆战，甚至添加一个简单的功能，或者修改一个BUG都会造成隐含的缺陷。一旦某一个模块出了问题，那基本就是全盘 GG。如果想针对某个具体模块提升性能，难度也比较大。

总的来说单体架构前期开发成本低、开发周期短，适合小型项目。对于大型项目来说不易开发、扩展和维护。技术栈受限，只能使用一种语言开发。系统性能扩展只能通过扩展集群节点，成本高。

单体架构优劣势：

优势	劣势
自包含单元 低延时 容易进行测试和运维 整个架构非常简单	很长的开发周期 很低的吞吐量 紧耦合低内聚 隔离性差 故障容忍度差 持续集成和部署困难 扩展性很差

（2）面向服务架构（SOA）

随着业务系统越来越复杂，单体架构垂直拆分演变出了SOA（ Service-Oriented Architecture），即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。比如上面举的这个 ERP 系统，可以按照功能，将用户，商品，交易等不同的部分拆分为了独立的服务（当然，数据库也需要进行拆分）。

 

 

从架构上来说，是将重复功能或模块抽取成组件的形式，对外提供服务，在项目与服务之间使用ESB（企业服务总线）的形式作为通信的桥梁。而ESB 就是一根管道，用来连接各个服务节点。为了集 成不同系统，不同协议的服务，ESB 做了消息的转化解释和路由工作，让不同的服务互联互通；

听起来这种方式比之前的单体架构厉害了不少，但还是会有一些对应的问题，比如每一个拆分之后的服务“依然还是单体服务”，有一些每个模块中都会使用的公共模块没有拆分（这也会导致 ESB 比较复杂）。
总结来说，面向服务架构有这些优劣势：

面向服务架构优劣势：

优势	劣势
服务解耦 服务隔离性好 可以进行持续集成和部署 容易测试和运维 集中式的服务治理 架构并不复杂	厚重和复杂的ESB 业务逻辑侵入ESB ESB 故障影响面太大 扩展性一般 开发周期适中 适中响应时间，低吞吐量

3）微服务架构

那如果我们不仅按照垂直方向拆分，同时也按照水平方向进行进一步拆分，那也就是微服务的架构模式了，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。其实和 SOA 架构类似，微服务是在 SOA 上做的升华。

 

 

还是以ERP系统举例，系统里的商品，用户，订单，库存等不同的部分都成为了独立的微服务，每一个服务之间都可以进行直接的通信沟通。

那么也就是说，微服务其实就是在移除了 ESB 之后，更为轻量和更为松耦合的服务，并把 ESB 的控制逻辑以 SDK 的方式注入到每个微服务中进行服务控制和治理，架构更为的分布式。

由于微服务的要素之一就是“微”，所以大多数微服务都是基于容器进行调度管理的（这也是我们为什么经常会在微服务的相关介绍中看到 Docerk，k8s 的相关字样）

微服务架构优劣势：

优势	劣势
开发周期短 松耦合，高内聚 高吞吐量 快速的持续部署 低故障影响，高可用 扩展性很好 开放的技术栈	测试和运维难度大 服务治理变困难 响应时间变长 架构非常复杂 技术门槛很高

从工作到现在经历过大大小小的几十个项目，每个项目都会基于当前的项目阶段、技术情况去选择合适技术架构。（很多大型企业的应用目前都还是单体架构）。随着技术的发展，随着业务的发展App版本不断迭代，新功能不断增加，业务上的处理逻辑越变越复杂。许多企业可能都面临着是否要将单体架构进行微服务升级改造的问题。但从一个大一统的系统，拆分成一个一个单独的小服务，企业需要投入的人力、物力、财力是非常巨大的。在没有足够的资源投入之前，不妨选择一些折中的方案。

传统架构的最大问题就是紧耦合，在应用迭代、升级的过程中，除了升级微服务架构之外，选择一些可插拔式的技术工具也可以很好的解决问题。比如：FinClip小程序容器技术 ，这是一种以小程序技术为载体，发展成组装式的企业应用架构技术。

从应用层来说，只要把FinClip SDK嵌入到企业的App中，就能立刻获得小程序运行能力。不管你的项目是什么软件架构，都可以通过这种嵌入式的小程序技术去获得APP并行开发、热更新、敏捷迭代的能力。

从开发角度来说，这是一种「Native + 小程序」的混合开发模式，借助这种模式可以让小程序运行在自有 App 中，将臃肿的 App 功能打散，功能模块互相解耦实现模块化开发，各业务模块间互不影响，通过管理后台即能实现实时动态更新与发布。对于一些积重难返的项目来说，采用这种入侵性小、可插拔式的技术是一种值得尝试的解决方案。

 

标签：指南,服务,单体,开发,软件架构,模块,架构,ESB
From： https://www.cnblogs.com/lydia77/p/17138546.html