分布式微服务架构及演变过程

微服务架构的演变：

微服务是一种松散耦合的，每个服务之间高度自治并且使用轻量级协议进行通信的可持续部署的分布式架构体系，这句话包含了微服务的特点，微服务架构和其他架构有什么区别 ? 以下是一些常见的软件架构：

一.单体应用架构：

单体应用架构是最简单的软甲架构，常用于传统的应用软件开发以及传统Web应用。传统Web应用，一般将所有功能模块都打包成（.jar/.war），在WEB应用服务器（Tomcat、Jboss、Jetty、webShare）中部署、运行。随着业务复杂度增加、技术团队规模扩大，在一个单体应用架构维护代码，会降低开发效率，即便处理一个小小的需求，也需要将所有机器上的的应用全都部署一遍，增加运维的复杂度。

弊端：被很多用户使用以后，就会产生一些严重的问题，CPU、硬盘有一个性能上限，假如一台只能接受5W同时访问的服务器，那假如有一年用户量暴涨到500W来访问就会出现：

1、服务器过载 CPU、内存、打满（服务器响应缓慢、宕机）

2、用户通过HTTP请求，每一次请求会发送一定数量的数据包、带宽被用尽-访问转圈圈，404无法访问

解决方法：

1.垂直扩容

可以通过更新硬件，提升带宽

2.水平扩容

前面讲到了用户出现了500W并发访问使用垂直扩容的方法可以解决，可以试想一下这样一个场景。假如经过几年的累加，用户量达到了5000W呢

解决方法：

集群架构模式

那么就可以多开几台服务器来解决服务器的压力，但是会出现一个问题就是每个服务器的属名不一致（IP地址不一致）。用户明明在注册界面注册了但是在登录的时候查不到他注册的信息登录不了，问题是怎么导致的呢，就是不同的服务器不同的端口接收的请求不同，导致数据不同步,该怎么解决请看下面的图：

下面不同的端口号代表一个个服务器用户去访问只访问qq.com10.123.243.220这个端口。通过负载均衡将所有请求，均衡分配给每一台服务器。（然后老板就会说做的做的好，加薪）

二.SOA架构

当某一天使用单体架构发现很难推进需求的开发、以及日积月累的技术债时，很多企业会开始做单体服务的拆分，拆分的方式一般有水平拆分和垂直拆分。垂直拆分是把一个应用拆成松耦合的多个独立的应用，让应用可以独立部署，有独立的团队进行维护；水平拆分是把一些通用的，会被很多上层服务调用的模块独立拆分出去，形成一个共享的基础服务，这样拆分可以对一些性能瓶颈的应用进行单独的优化和运维管理，也在一定程度上防止了垂直拆分的重复造轮子。

SOA 也叫面向服务的架构，从单体服务到 SOA 的演进，需要结合水平拆分及垂直拆分。SOA 强调用统一的协议进行服务间的通信，服务间运行在彼此独立的硬件平台但是需通过统一的协议接口相互协作，也即将应用系统服务化。

举个易懂的例子：

单体服务如果相当于一个快餐店，所有的服务员职责都是一样的，又要负责收银结算，又要负责做汉堡，又要负责端盘子，又要负责打扫，服务员之间不需要有交流，用户来了后，服务员从前到后负责到底（一条龙服务）。SOA 相当于让服务员有职责分工，收银员负责收银，厨师负责做汉堡，保洁阿姨负责打扫等，所有服务员需要用同一种语言交流，方便工作协调(分工合作)。

再回头去看最上面的图片，你会发现用户管理、订单管理、支付管理都是一起执行的，要崩溃就一起崩溃，要运行就一起运行。而且在公司项目都会分开来做，一旦报错，责任都不好追究。每个人就互甩锅，做用户组的说没有错，做支付的也说没有错。老板啪的一声全部留下来加班，但是如果将他们拆分就能了，哪个组不通过就留下来加班。同时在几年后的今天用户量达到了5个亿，那么该怎么办呢。那有人就会说了再在原有的服务器上扩充个十倍不就好了，一台好的服务器市场价是200W 那么原有10台服务器的基础上扩充十倍就是两个亿，老板脸都可能青了。请那么多人来就是败公司的？这时候老板就会想我不如花点钱请专家来设计一下。节约一下成本如图所示：

这时候专家就总体分析了一遍，把常用的和不常用的划分开来，通过验证发现使用支付的占了%80，其他的只占了20%。90%业务处于数据读取查询，10%写入。所以给18台服务器专门做支付，其他的服务器做其他。这样子既节约了成本，还划分了区域。仔细的算笔帐，会发现原来需要100台服务器，现在22台服务器就做到了。一下省了一亿多的米，这是一个普通人几辈子的赚不到的。
那么恭喜这位专家，盆满钵满的唱着征服回家了（被自己的技术魅力征服了）。

微服务和SOA

微服务也是一种服务化，不过和SOA架构的服务化概念还是有区别的，可用以下关键字理解：

松耦合：

每个微服务内部都可以使用DDD（领域驱动设计）的思想进行设计领域模型。服务器尽量减少服务器的调用，多使用消息的方式让领域时间进行解耦

轻量级协议：

Dubbo是SOA开源标准实现之一，类似还有像RPC、Thrift等，微服务更倾向于Restful风格的API。轻量级协议很好的支持跨语言开发的服务，所有的语言都有一个共同点就是支持Http协议通信。

高度自治和持续集成：

从底层的角度来说，SOA更加倾向于服务器和虚拟机的部署。每个应用部署在不同的机器上，一般持续集成工作更多的是运维团队写一些Shell脚本以及提供基于共同协议的开发部署页面（比如Dubbo管理页面）。微服务可以很好的和容器技术结合，容器技术比微服务出的晚，但是容器技术的出现让微服务实施更加方便。目前Decker已经成为很多微服务实践的基础。因为容器的特点，所以一台机器上可以部署几十个甚至上百个不同的微服务，如果某个微服务的流量压力比其他微服务大，可以在在不增加机器的基础上。在一台机器上多分配该微服务的容器实例。同时，因为 Docker 的容器编排社区日渐成熟，类似 Mesos、Kubernetes 及 Docker 官方提供的 Swarm 都可以作为持续集成部署的技术选择。

其实从架构的演进的角度来看，整体的演进都是朝着越来越轻量级、越来越灵活的应用方向发展，甚至到近两年日渐成熟起来的 Serverless（无服务）架构。从单体服务到分层的服务，再到面向服务、再到微服务甚至无服务，对于架构的挑战是越来越大

微服务和SOA都属于典型的分布式架构，只不过微服务部署的粒度更细，服务扩展更灵活。

微服务中的分布式

微服务的分层不仅仅是容器应用层面的分布式，其为了高度自治，底层的存储体系也应该相互独立。并不是所有的微服务都需要持久的存储服务。就像一个“手机验证码”微服务可能底层存储就用到一个非关系型数据库Redis；一个”营销活动搭建页面“微服务可能就底层存储就使用mongoDB。

三、分布式微服务架构

那么分布式到底是什么样的呢，可以看到服务器变成了服务、如图所示：

相比前面的架构而言

微服务是真正的分布式的、去中心化的。把所有的“思考”逻辑包括路由、消息解析等放在服务内部，去掉一个大一统的 ESB，服务间轻通信，是比SOA更彻底的拆分。
分布式微服务架构强调的重点是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维数据的小应用，这些小应用之间通过服务完成交互和集成。

可以分为六个组件

（1）业务接入层：

（请求的分发）：服务间路由和调度网关

（2）业务服务层：

各个功能模块服务比如：支付，用户，订单

（3）服务注册中心：

提供服务的注册和发现以及编排和管理的功能,维护一个可用分的服务列表，当你在服务层上线了一个服务后必须要先在服务注册中心注册一下和我们签到是一个意思如下：

服务注册中心自带了一个”心跳机制“

心跳机制，每隔30秒会对每个服务发送一个非常小的请求，探测其他的服务还能不能被继续使用,一旦发现不可用，就会从可用列表移除掉，就不会被访问了，当服务恢复，Eureke下次心跳机制就会重新上线这个服务

（4）RPC：

（远程工程的调用）：每个独立的服务项目之间的调用

（5）配置中心：

将配置的参数统一管理的场所

（6）消息中间介：

记录用户发起的请求，各个服务可以通过定时任务或者自由访问消息中间介中的请求。

把原来的同步响应模式变成了异步响应模式。提升用户的响应时间，隐藏实现细节。

1.服务注册中心（Eurreck）（CAP理论重点）

帮助我们管理所有业务服务，维护一个可用的服务列表。

为什么维护列表需要用到CAP理论呢？

而也因为分布式微服务架构是一个真正的分布式架构项目里的功能模块都是独立开来的包括数据也是独立的，这就会造成数据不同步。

假如我用户管理修改了年龄但由于我其他的功能模块是独立的数据所以就不同步这就是一个很严重的问题，那么就得使用CAP理论来解决这个严重的问题了

（1）C 数据一致性：

分为强数据一致性和最终数据一致性，强数据一致性就是当你在某个服务中修改了数据那么其他服务就必须将数据同步（数据同步时会造成短暂的不可访问状态），最终一致性字面意思就是最终提交的数据我要他是数据同步
不管你前面改了啥反正我最后提交的时候要数据同步提交

（2）A 可用性：

提供业务访问的可用时间，就是你服务是不是可用一直开着可用一直访问
一般都是999 99999 这样子一个礼拜停那么一两个小时或者一个月停那么一两个小时可以率99%，争取做到无限接近百分百

（3）P 分区容错率（必须满足）

可以容忍某个服务不可用但是必须不能影响整体服务器的运行

可以看出来可用性和数据一致性是互斥的（