软件架构演进之路

单体式架构的时代 

单体式架构(Monolithic)

单体式架构就是将所有业务场景中的表示层、业务逻辑层和数据访问层放在一个工程中，最终经过编译、打包为war包或jar包，部署在一台服务器上。

通俗的说法：如果一个war包或者jar包里面包含一个应用的所有功能，则是单体式架构。

早期的SSH和SSM项目大多是单体式架构的项目。

优点

        架构简单、运维简单。开发成本低，开发周期短。

缺点

        1、系统启动慢， 一个进程包含了所有的业务逻辑，涉及到的启动模块过多，会导致系统的启动、重启时间周期过长;

        2、系统错误隔离性差、可用性差，任何一个模块的错误均可能造成整个系统的宕机;

        3、可伸缩性差：系统的扩容只能对整个应用扩容，成本高。不能做到对某个功能点进行扩容;

        4、技术栈受限：只能使用1种开发语言；

适用场景

        1、适用于业务不复杂、访问量较小的项目

        2、例如：政府项目、管理系统、crm客户关系管理系统

单体式架构面临诸多问题

宽带提速，网民增多

时间的年轮来到2004年，随之到来的WEB2.0时代，实现的ADSL拨号上网，宽带提速，最高可以达到8M，用户量也就不断增加，一些门户网站也开始活跃，项目就需要考虑安全性和稳定性，如果服务器发生宕机，则整个应用也随之崩溃

Web2.0时代的特点

Web2.0模式下的互联网应用具有以下显著特点：去中心化、开放、共享。

1、用户分享。在Web2.0模式下，可以不受时间和地域的限制分享各种观点。用户可以得到自己需要的信 息也可以发布自己的观点。

2、信息聚合。信息在网络上不断积累，不会丢失。

3、以兴趣为聚合点的社群。在Web2.0模式下，聚集的是对某个或者某些问题感兴趣的群体，可以说，在无形中已经产生了细分市场。

4、开放的平台，活跃的用户。平台对于用户来说是开放的，而且用户因为兴趣而保持比较高的忠诚度，他们会积极的参与其中。

问题描述

产品最终的核心是产品的长期运行，作为公司，肯定希望这个产品被越来越多的人使用，这样才能创建更大的价值。

对于整个技术架构来说，可能会面临以下挑战

用户量增多，访问量不断增大，导致后端服务器的负载越来越高

用户量增多，产品需要满足不同用户的需求来留住用户，使得业务场景越来越多并且越来越复杂。

业务场景越多越复杂，意味着war包或jar包中的代码量会持续上升，耦合度也会越来越高。后期的代码维护和版本发布也会很困难。

优化的方向

通过横向添加服务器，把单台变成多台机器的集群；

按照业务维度把项目切割成多个项目，减少业务的耦合度，以及降低单个war包或jar包带来的伸缩性困难的问题。

搭建集群

解决方案

在单体架构的基础上去搭建集群。如果一台服务器发生宕机，其他服务器可以继续运行，同时多台服务器也能分担大量用户访问的压力

集群

集群就是单机的多实例，在多个服务器上部署多个服务，每个服务就是一个节点，这些节点的集合就叫做集群。

优点

操作简单，容易部署。

缺点

每个节点负载相同（耦合度高），每个具体业务的访问量可能差异很大，比如美团外卖美食外卖的访问量一定大于鲜花外卖的访问量，这就造成了资源浪费。

适用场景

单机处理到达瓶颈的时候，你就把单机复制几份，这样就构成了一个“集群”。 集群中每台服务器就叫做这个集群的一个“节点”，所有节点构成了一个集群。每个节点都提供相同的服务，那么这样系统的处理能力就相当于提升了好几倍。集群部署，它是把相同应用复制到不同服务器上，但是逻辑功能上还是单体应用。

优点

在搭建集群之后，可以提升项目的稳定性，并且并发量增加，也可以承受住。

产生的问题

用户请求问题

用户的请求到底要发送到哪台服务器上，如何保证请求平均的分发给不同的服务器，从而缓解用户量增加点压力

用户的登录信息

编写项目是，如果用户登录成功了，将用户的标识放到 session 域中，在搭建集群之后如何实现数据共享问题

数据查询

当数据量特别庞大时，如果还直接去数据库查询，速度很慢，如何提升查询效率

为了解决上述问题，需要使用的三门技术

Nginx 解决用户请求分发，负载均衡

Redis 解决数据共享并实现缓存功能

ElasticSearch \ Solr 解决搜索数据的功能

 改进后的架构

垂直架构的出现

比如一个电商项目包含了三个模块,用户模块,商品模块,订单模块

商品模块压过大,一般最直接有效的方式就是搭建集群，在单体架构的集群上去搭建,效果 相对比较差，需要在每个服务器上都部署商品模块，用户模块,订单模块

随着项目的不断更新,项目中的功能越来越多,最严重可能会导致项目无法启动

为了解决上述的各种问题演进出了垂直架构

优点

        拆分后业务直接的相互影响小，减少耦合度，能合理地分配硬件资源；

        配合集群后从而提升整个系统的吞吐量；

缺点

        可能会导致整个系统存在“重复造轮子”的问题，而且难于维护

分布式架构的出现

随着项目的不断迭代,新老功能之间需要相互交互,服务器和服务器之间是需要通讯的。我们无法直接实现通讯，怎么解决？

项目一般是分为三层的,Controller,Service,Dao。导致程序变慢的重灾区一般是service和Dao,在搭建集群时,确实针对三层都搭建集群，效果不是很好，怎么解决？

为了解决上述的各种问题架构从垂直架构演变到了分布式架构. 实现了模块之间的通讯

分布式架构

分布式架构（Distributed Service Architecture，DSA）就是将一个完整的系统，按照业务功能，拆分成一个个独立的子系统，

在分布式结构中，每个子系统就被称为“服 务”。这些子系统能够独立运行在web容器中，它们之间通过RPC方式通信。

分布式和集群的区别

        集群是个物理形态，分布式是个工作方式

        分布式：一个业务分拆多个子业务，部署在不同的服务器上。

        集群：同一个业务，部署在多个服务器上。

        分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内 执行的任务数来提升效率。

        如果一个任务由10个子任务组成，每个子任务单独执行需1小时，则在一台服务器上执行该任务需10小时。

        采用分布式方案，提供10台服务器，每台服务器只负责处理一个子任务，不考虑子任务间的依赖关系，执行完这个任务只需一个时。而采用集群方

案，同样提供10台服务器，每台服务器都能独立处理这个任务。假设有10个任务同时到达，10个服务器将同时工作，1小时后，10个任务同时完成，这

样，整身来看，还是1小时内完成一个任务。

出现的问题

场景假设

场景1：假设用户执行下单操作，系统的处理逻辑是先去库存子系统检查商品的 库存，如果库存充足的情况下才会提交订单，那么这个检查库存的逻辑是

放在订 单子系统中还是库存子系统中呢？这些业务场景的逻辑可能会被重复创建，从而产生冗余的业务代码。能不能把这些共享业务逻辑抽离出来形成可

重用的服务呢？

场景2：在一个集团公司下有很多子公司，每个子公司都有自己的业务模式和信 息沉淀，各个子公司之间不进行交互和共享。由于各个子公司之间信息不

是互联互通的，彼此之间形成了信息孤岛，使得价值无法最大化

优化的方向

把一些通用的、会被多个上层服务调用的共享业务提取成独立的基础服务，并且可以重用。

SOA 架构

        当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加 一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)[ Service Oriented Architecture]是关键。

        SOA（Service-Oriented Architecture）是基于分布式架构演变而来，俗称服务化，也就是面向服务开发，将共同存在的业务逻辑抽取成一个公共的服务，提供给其他结构实现调用，服务与服务之间采用RPC远程调用技术。

服务里只有业务逻辑，没有视图层。

特点：

SOA架构模式传输协议采用SOAP协议（http/https+XML）实现传输，在高并发情况下实现通讯该协议存在大量的冗余性传输，非常占用带宽。

SOA架构模式实现方案为Web Service或者ESB企业服务总线

出现的问题

SOA架构的问题

        SOAP协议实现通讯，XML传输非常重，效率比较低

        服务化管理和治理设施不够完善。

        依赖于中心服务发现机制

        不适合前后端分离架构模式

优化的方向

        去除SOA架构中SOAP协议和ESB企业服务总线，改为http+json形式传输接口

        服务的粒度更加精细化，提倡让专业的人去做专业的事。每个服务互不影响。每个服务都是单独独立数据库、Redis连接、MQ等。并且都是独立部署，整个服务架构更加轻巧。

微服务架构出现了

微服务的概念源于2014年3月Martin Fowler（马丁·福勒，微服务的提出者）所写的一篇文章Microservices（https://martinfowler.com/micr

oservices/）。微服务架构风格是一种将一个单体应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制

(通常是基于HTTP协议的RESTful API)。这些服务围绕业务能力构建，并且可通过全自动部署机制独立部署。 这些服务共用一个最小型的集中式的管理，

服务可用不同的语言开发，使用不同的数据存储技术。

微服务架构的特征

        每个服务按照业务划分；

        服务之间通过轻量级 API 调用；

        可以使用不同语言开发；

        可以使用不同的数据存储技术；

        可独立部署，服务之间互相不影响；

        可针对用户访问流量大的服务单独扩展，从而能够节约资源；

        管理自动化

优点

        逻辑清晰，项目复杂度降低：通过对共享业务更加细粒度的拆分，一个服务只需要关注一个特定的业务领域，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，开发、维护会更加简单；

        技术选型更加灵活：每个微服务都有不同的团队来维护，所以可以结合业务特性自由选择技术栈；

        可扩展性更强：可以根据每个微服务的性能要求和业务特点对服务进行灵活扩展；

        独立部署：单个微服务的代码量比较小，使得发布更加高效；

        容错性：如果某一个服务发生故障，可以通过重试、降级等机制实现容错；

缺点

        性能降低，微服务的间通过REST、RPC等形式进行交互，通信的延时会受到较大的影响；

        提升了运维的难度（版本发布、问题排查、配置管理、监控)；

        数据一致性的问题;

微服务架构面临的挑战

        微服务粒度大小难以划分，需要设计人员对业务有很好的掌握；

        分布式复杂性，主要体现在分布式事务、网络延迟、系统容错等问题解决难度较大；

        微服务之间通信成本较高，对微服务之间网络稳定性、通信速度要求较高；

        由于微服务数量较大，运维人员运维、部署有较大的挑战

技术挑战

        微服务架构的主要目的是实现业务服务的解耦；

        对服务进行治理（服务的注册与发现、服务与服务之间的调用、熔断限流、负载均衡、链路追踪、分布式配置中心、服务路由等）；

微服务 VS SOA

通讯协议

        微服务只是一种为经过良好架构设计的SOA解决方案，是面向服务的交付方案。

        微服务架构继承了SOA架构优点，在微服务架构中去除SOA架构中SOAP协议和ESB企业服务总线，改为http+json形式传输接口。

服务拆分

        微服务架构比SOA架构的粒度更加精细，提倡让专业的人去做专业的事。每个服务互不影响。 每个服务都是单独独立数据库、redis连接、MQ等。并

且都是独立部署，整个服务架构更加轻巧。

项目迭代

        服务拆分微服务与敏捷开发的思想高度结合在一起，服务的定义更加清晰，同时减少了企业ESB开发的复杂性

主流的微服务框架