分布式微服务架构演进过程

架构演进

一、开发环境与生产环境

---

1.1 开发环境

平时在写代码时，大多都在是Win10/Win7/Mac，这些系统都可以称呼为开发环境，会为了更高效的开发应用程序，会安装很多很多的软件，导致操作系统不安全，稳定性降低。

1.2 生产环境

在生产环境中，操作系统不会采用Win10/Mac，这种操作系统相对不安全，生产环境是要面向全体用户的，一般会采用专业的操作系统。

大多市面上使用的都是基于Linux的操作系统，当然还有Windows版本的服务器操作系统，如Windows 2003 service等等。

由于Linux内核版本完全对外开源，市场占用率大，所以第一步要学会如何使用Linux操作系统。

二、Web1.0&Web2.0阶段

---

2.1 Web1.0阶段

在Web1.0阶段，由于带宽不足，这时的项目大多是内容少，用户量不多，甚至有一些项目不需要对外开放，对安全性和稳定性的要求不高。

单体架构就足以应对。

单体架构

2.2 Web2.0阶段

随之到来的Web2.0阶段，实现了ADSL拨号上网，宽带提速，最高可以达到8M，用户量也就不断增加，一些门户网站也开始活跃，项目就需要考虑安全性和稳定性。

在基于上面的单体架构图中，无法满足Web2.0对项目的需求。

可以选择在单体架构的基础上去搭建集群。

在搭建集群之后，可以提升项目的稳定性，提升并发能力，避免单点故障。

单体架构搭建集群

2.3 搭建集群后的问题

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

项目中，如果用户登录成功了，将用户的标识放到Session域中，在搭建集群之后，Session数据共享问题。

由于用户量增加，热点数据被查询的频率增高，数据库压力骤增，甚至导致数据库宕机。

在搜索一些数据时，会使用where content like '%#{xxx}%'查询条件，会导致索引失效，检索速度极慢。

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

  • Nginx - 解决用户请求平均分发。

  • Redis - 解决数据共享并实现缓存功能。session复制/去状态化

  • ElasticSearch - 解决搜索数据的功能。

使用各种中间件

三、垂直架构

---

项目包含了三个模块，用户模块，商品模块，订单模块。如果商品模块压过大，一般最直接有效的方式就是搭建集群。在单体架构的集群上去搭建，效果相对比较差。

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

基于上述情况，单体架构完美的体现了低内聚，高耦合，避开了开发的准则。

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

但是各个模块之间可能存在相同的业务

• 系统拆分实现了流量分担，解决了并发问题
• 可以针对不同模块进行优化
• 方便水平扩展，负载均衡，容错率提高
• 系统间相互独立

垂直架构图

四、SOA架构

随着对业务系统进行垂直化改造之后，以业务功能纬度拆分出来多个子系统， 而在各个子系统中，会存在比较多的共享业务，比如用户信息查询，在支付业务中会涉及到、在首页中也会涉及到。那么势必会造成重复开发产生非常多的冗余代码。 那么这个时候就引入了服务化改造的思想，也就是 SOA把一些通用的、会被多个上层服务调用的模块独立拆分出来，形成一些共享的基础服务。这些被拆分出来的共享服务相对来说是比较独立，并且可重用。 比如用户管理服务，包含用户注册、用户查询等功能。比如单点登录服务；

SOA 的核心目标就是通过服务的流程化来实现业务的灵活性，而这个流程化其实就是一系列相关联的任务组成，这一系列相关联的任务可以通过一系列的服务组合来实现具体的业务功能SOA 面向服务架构，从语义上说，它与面向过程、面向对象、面向组件一样，是一种软件组建及开发的方式。所以在 SOA 中，服务是最核心的抽象手段，业务被划分为一些列粗粒度的业务服务和业务流程

SOA 中更强调 ESB 企业服务总线，企业服务总线可以使得服务之间的交互是动态的，以及服务位置是透明的。这样的好处是服务的调用者和服务的提供者之间是高度解耦的。从而使得服务有更高的灵活性以及隔离性。

SOA架构图

ESB： 是从面相服务架构(SOA)发展过来的，主要是对多个系统中的服务调用者和服务提供者的解耦。 ESB 本身提供了服务暴露、接入、协议转化、数据格式转化、路由等功能。

SOA 主要解决的问题：

• 信息孤岛

• 互联互通

• 业务重用

五、分布式架构

---

随着项目的不断迭代，新老功能之间需要相互交互，服务器和服务器之间是需要通讯的。

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

架构从垂直架构演变到了分布式架构。

• 分布式架构落地的技术，国内常用的方式有两种

  • Dubbo——RPC（通讯方式）

  • SpringCloud——HTTP（通讯方式）

分布式架构图

六、分布式架构常见问题

---

6.1 服务之间的异步通讯

使用分布式架构之后，服务之间的通讯都是同步的。在一些不是核心业务的功能上，可以实现异步通讯，以加快处理速度，可以更快的给用户响应。

为了实现服务之间的异步通讯，可以采用RabbitMQ等消息队列中间件。

分布式架构下，实现异步通讯

6.2 服务之间通讯地址的维护.

由于服务越来越多，每个服务的访问地址方式都是通过：协议://地址:端口号/路径

由于模块繁多，并且模块搭建的集群数量增加，会导致其他模块需要维护各种ip地址等信息，导致项目的维护成本极高，耦合性增加，并且实现负载均衡也变得很麻烦。

• 可以采用以下技术来解决当前问题:

  • Eureka注册中心管理服务信息。

  • Ribbon实现服务之间的负载均衡。

Eureka实现通讯地址维护，Ribbon实现服务之间的负载均衡

6.3 服务降级

在上述的架构中，如果说订单模块出现了问题，只要是涉及到订单模块的功能，全部都无法使用，甚至可能会导致服务器提供的线程池耗尽。给用户友好的提示都是无法做到的。

• 为了解决上述的问题，可以采用Hystrix处理：
  • Hystrix提供了线程池隔离的方式，避免服务器线程池耗尽，在一个服务无法使用时，还提供断路器的方式来处理问题服务，从而执行降级方法，返回托底数据。

注意： Eureka，Ribbon，Hystrix都是SpringCloud技术栈中的组件。

使用Hystrix帮我们提供断路器和隔离，并最终服务降级

6.4 海量数据

海量数据会导致数据库无法存储全部的内容，即便数据库可以存储海量的数据，在查询数据时，数据库的响应时极其缓慢的，在用户高并发的情况下，数据库也时无法承受住的。

为了解决上述的问题，可以基于MyCat实现数据库的分库分表。

基于MyCat实现分库分表

七、微服务架构

---

7.1 微服务架构

微服务架构是分布式架构中的一种方式：实际就是将软件应用程序设计为可独立部署的服务的特定方式。

尽管没有微服务架构风格的精确定义，但围绕业务能力，自动部署，对语言的和数据的分散控制，组织周围存在某些共同特征。

SpringCloud作为微服务架构落地的技术栈，可以快速实现微服务架构。

SpringCloud微服务架构图

7.2 模块过多，运维成本增加

微服务架构中每个服务都是独立部署的，对运维成本的增加是不可估量的。

可以采用Docker容器化技术来帮助我们管理各个模块的部署，还可以通过CI、CD持续集成，持续交付，持续部署。

解决这个问题可以使用Docker来帮助我们快速的安装软件。

Docker容器化技术

7.3 分布式架构下的其他问题

分布式架构帮助我们解决了很多的问题，但是随之也带来了很多问题

7.3.1 分布式事务

最传统的操作事务的方式，是通过Connection链接对象的方式操作，Spring也提供了声明式事务的操作。

为了解决事务的问题，后续会使用到RabbitMQ、RocketMQ或者LCN等方式来解决。

7.3.2 分布式锁

传统的锁方式，synchronized | Lock锁，在分布式环境下，传统的锁是没有效果的。

为了解决锁的问题，后续会使用到Redis或者Zookeeper来解决。

7.3.3 分布式任务

在传统的定时任务下，由于分布式环境的问题，可能会造成任务重复执行，一个比较大的任务，需要可以拆分。

为了解决这个问题，后续会使用到Redis + Quartz或者Elastic-Job来解决。