【初出江湖】剖析软件架构发展之路

本文主要是介绍【初出江湖】剖析软件架构发展之路，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

架构发展历程

单体架构（Monolithic）

单体应用时代：应用程序无论如何分层，都是一个解决方案，或者说都是一个项目，这里的“解决方案”和“项目”不是我们使用的Visual Studio里面的概念，最终的程序代码都会在一个进程里运行。

• 优点：开发简单，集中管理，没有分布式的损耗，都是系统进程内的通信。
• 缺点：不好维护，升级困难，耦合严重，无法应付高并发和大数据场景，无法快捷迭代。

垂直拆分

随着业务规模的越来越庞大，系统设计就越来越复杂，大的系统就开始进行业务的垂直拆分。比如：有专门做商品秒杀的部门，有专门做生鲜商品的部门，有专门做超市的部门，等等，当然这是根据部门天生划分的，也有根据业务需求进行系统划分的。

• 优点：垂直拆分，系统独立部署和维护，每个系统在自己进程内执行，分而治之。
• 缺点：拆分越多，存储越复杂，系统间重复的东西也越多，单个系统还是单体模式。

分布式服务

随着业务系统的越来越庞大，软件系统设计起来越来越复杂。为了避免过度复杂的业务需求，开始对业务系统的进行垂直拆分，形成多个独立的业务系统，如果多个系统之间要通信，可以通过跨进程的技术完成通讯。但是垂直拆分也导致了大量重复代码、重复模块的产生，比如：用户模块、日志模块、支付模块、认证授权模块等，这样分散的代码也给系统的维护和升级带来了困难。我们对业务重新划分，把独立的模块接口化、服务化，提高重用，这个时候，我们就开始进入了分布式服务的时代。

优点：

• 独立进程部署，独立进程运行，独立演化。服务之间可以做到高内聚，低耦合。
• 独立开发和维护，业务解耦，无论是业务系统还是分布式服务都独立演化。
• 分布式管理
• 隔离性增强
• 由一系列服务组装成系统，不用重复建设，模块、代码可以复用。

缺点：

• 数据一致性（多服务完成一个任务）和系统的可用性（集群）成为问题
• 数据库也进行了拆分
• 维护、设计、架构成本增加，调试、纠错更难
• 网络传输分布式损耗成本
• 不适合高并发和大数据的环境

微服务架构

微服务的出现时分布式架构已经很成熟了，架构中各种问题已经有了很成熟的解决方案，对于现在的业务系统来说，分布式架构已经变成了一种常规手段，这个时候，微服务就出现了。微服务架构是一个用分布式服务拆分业务逻辑，完成解耦的架构模式（架构风格）。微服务肯定是分布式的一种，是在分布式技术成熟之后，然后把分布式当成解耦手段来架构系统——因为拆分的服务很细致，服务数量规模开始变多了，服务的体量开始缩小了，由以前几个大的服务，转变为多个独立运行的、原子性质的服务。如图：

微服务最重要的特性是：

• 可用性：描述一个系统在一段时间内提供有用资源的能力，从而减少停工时间，而保持其服务的高度可用性。
• 伸缩性：根据需求动态添加和删除系统中资源的能力，是水平或垂直扩展的专门实现。

集群（负载均衡）可以解决系统的高可用和伸缩特性。

优点：

• 可以使用不同语言或者相同语言的不同版本开发各个模块。
• 系统耦合性低，各个模块分而治之，独立部署，独立发布，独立维护。
• 可以更快的相应市场的需求，更符合敏捷开发。
• 可以对不同模块使用集群策略，哪里有问题治哪里。

缺点：

• 开发难度更大，系统结构更复杂。
• 运行效率低，网络调用成本很大。

SOA

SOA----面向服务架构，实际上强调的是软件的一种架构，一种支撑软件运行的相对稳定的结构，表面含义如此，其实SOA是一种通过服务整合来解决系统集成的一种思想。不是具体的技术，本质上是一种策略、思想。

简单的理解，我们可以把SOA看作是模块化的组件，每个模块都可以实现独立功能，而不同模块之间的结合则可以提供不同的服务，模块之间的接口遵循统一标准，可以实现低成本的重构和重组。在SOA的技术框架下，可以把杂乱无章的庞大系统整合成一个全面有序的系统，从而增加企业在业务发展过程中应用系统的灵活性，实现最大的IT资产利用率。

SOA是一种理念，有去中心化和中心化两种实现方式，ESB是SOA的中心化实现。SOA的特征：可重用、松耦合、明确定义的接口、无状态的服务设计、基于开放标准。解决了分布式的缺点。SOA体系结构中的角色包括：服务请求者、服务提供者、服务注册中心。实际上SOA只是一种架构设计模式，而SOAP、REST、RPC就是根据这种设计模式构建出来的规范！

ESB

ESB----企业服务总线，像一根“聪明”的管道，用来连接各个“愚笨”的节点。为了集成不同系统，不同协议的服务，ESB做了消息的转换解释与路由等工作，让不同的服务互联互通。

分布式

分布式系统面向的是运维，更多的是考虑系统性能和部署环境之间的问题，通过分布式解决在没有大型主机的部署环境情况下，系统性能的高可用和吞吐量，是个一个很早就提出来的一个概念，是由集中式系统过渡来的，随着计算机系统向网络化和微型化的发展日趋明显，同时业务的发展，传统的集中式处理模式越来越不能适应人们的需求，学习成本高，大型主机贵、容错性差，扩容困难。

为了解决业务快速发展给IT系统带来的巨大挑战,从2009年开始,阿里集团启动了去IOE计划,其电商系统开始正式迈入分布式系统时代。

在《分布式系统概念与设计》生一书中,对分布式系统做了如下定义:

「分布式系统是一个硬件或软件组件分布在不同的网络计算机上,彼此之间仅仅通过消息传递进行通信和协调的系统。」

微服务

微服务 (Microservices) 是一种软体架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building
Blocks) 为基础，利用模组化的方式组合出复杂的大型应用程式，各功能区块使用与语言无关
(Language-Independent/Language agnostic) 的API 集相互通讯。 微服务的起源是由 Peter
Rodgers 博士于 2005 年度云端运算博览会提出的微 Web 服务 (Micro-Web-Service) 开始，Juval
Löwy 则是与他有类似的前导想法，将类别变成细粒服务 (granular services)，以作为 Microsoft
下一阶段的软体架构，其核心想法是让服务是由类似 Unix 管道的存取方式使用，而且复杂的服务背后是使用简单 URI
来开放介面，任何服务，任何细粒都能被开放 (exposed)。这个设计在 HP 的实验室被实现，具有改变复杂软体系统的强大力量。
2014年，Martin Fowler 与James
Lewis共同提出了微服务的概念，定义了微服务是由以单一应用程式构成的小服务，自己拥有自己的行程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用
HTTP API 通讯。同时服务会使用最小的规模的集中管理 (例如 Docker) 能力，服务可以用不同的程序语言与资料库等元件协作。

微服务架构更多的是面向开发,更多的是考虑编码和项目业务之间的问题,根据功能把应用拆分为服务。解决的是开发问题和应用复杂性，是在对于业务的快速发展中单体应用不能满足需要的时候，提出来的一个概念！

在《微服务架构设计模式》一书中对微服务架构做如下定义：把应用程序功能性分解为一组服务的架构风格。

SOA，ESB，微服务的区别和关系

我们看到微服务架构的些特点与 SOA 服务化架构相似， 事实上微服务架构与 SOA服务化架构并不冲突，它们一脉相承，却略有不同：

区别	说明
目的不同	微服务使用 系列的微小服务来实现整体的业务流程，目的是有效地拆分应用，实现敏捷开发和部署，在每个微小服务的团队里，减少了跨团队的沟通，让专业的人做专业的事，缩小变更和迭代影响的范围，并达到单一微服务更容易水平扩展的目的。SOA 服务化涉及的范围更广 些，强调不同的异构服务之间的协作和契约 ，并强调有效集成、业务流程编排、历史应用集成等，典型代表为 Web Service 和ESB。
部署方式不同	微服务将完整的应用拆分成多个细小的服务，通常使用敏捷扩容、缩容的 Docker 技术来实现自动化的容器管理 每个微服务运行在单 的进程内，微服务中的部署互相独立互不影响。SOA 服务化通常将多个业务服务通过组件化模块方式打包在 War 包里，然后统部署在一个应用服务器上。
服务粒度不同	微服务倡导将服务拆分成更细的粒度，通过多个服务组合来实现业务流程的处理，拆到职责单一，甚至小到不能再进行拆分。SOA对粒度没有要求，在实践中服务通常是粗粒度的，强调接口契约的规范化，内部实现可以更粗粒度。

SOA去中心化的实现方式的根本诉求是扩展性，实现方式就是微服务。

分布式与微服务之间的区别于关系

「分布式系统」 更多是偏水平扩展，在ops方面的解决办法，利用部署系统环境的空间分布性，比如SOA架构中利用分布式集成大型、复杂的单体应用程序；比如对实例进行克隆，以副本的形式对应用的数据和服务提供一种冗余方式(数据副本和服务副本)，从而对外提供高可用，高并发的服务。分布式需要解决分布式数据一致性以及分布式环境通信异常、网络分区等问题。比如通过Zookeeper解决分布式数据一致性的问题。分布式系统可以理解为以解决硬件层面的压力从而对应用进行扩展。

「微服务架构」 更多的是垂直方向的扩展，在dev方面解决问题，利用应用程序的功能性分解,，把应用拆分为一组服务，每个服务负责特定的功能。每个服务都相对较小并容易维护，使大型的复杂应用程序可以持续交付和持续部署。服务可以独立部署、可以独立扩展。同时微服务架构可以实现团队的自治。更容易实验和采纳新的技术。更好的容错性。即服务之间松耦合，但是单个服务又是高内聚的。微服务架构可以理解为解决软件层面的压力对应用进行扩展。

两者不属于包含关系，都是对于应用扩展的不同解决办法。一般情况下，微服务架构的应用一般为分布式系统。但分布式系统不一定是微服务架构。

这篇关于【初出江湖】剖析软件架构发展之路的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---