微服务架构优势在哪，与传统服务又有什么区别呢？

一、概述

说起微服务，在程序界，可算是当下相对火爆的词，那么微服务到底是什么？与传统的服务有什么区别，为什么要使用微服务呐？

需要指出的是：微服务架构并不是为了拆分而拆分，真正的目的是通过对微服务进行水平扩 展解决传统的单体应用在业务急剧增长时遇到的问题，而且由于拆分的微服务系统中专业的人做 专业的事，人员和项目的职责单一、低藕合、高内聚，所以产生问题的概率就会降到最小。

二、微服务架构描述

先看看微服务的架构图，看看当前火的微服务架构图：

从图得出如下结论：

· 微服务把每一个职责单一的功能放在一个独立的服务中 。
· 每个服务运行在一个单独的进程中。
· 每个服务有多个实例在运行，每个实例可以运行在容器化平台内，达到平滑伸缩的效 果。
· 每个服务有自己的数据存储，实际上，每个服务应该有自己独享的数据库、缓存、消息 队列等资源。
· 每个服务应该有自己的运营平台，以及独享的运营人员，这包括技术运维和业务运营人 员：每个服务都高度自治，内部的变化对外透明。
· 每个服务都可根据性能需求独立地进行水平伸缩 。

三、传统架构描述

先看看传统架构图，粗略看看传统架构的实现方式：

从上图可以得到如下结论：

·传统单体架构将所有模块化组件混合后运行在同一个服务 口而4 进程中 。
· 可对包含多个模块化组件的整体 川岛f 进程进行水平扩展，而无法对某个模块化组件进 行水平扩展。
· 某个模块化组件发生变化时，需要所有的模块化组件进行编译、打包和上线 。

· 久而久之，模块间的依赖将会不清晰，互相糯合、互相依赖成为家常便饭。

通过对比来看，微服务架构更灵活并且可水平伸缩，可以让专业的人来做专业的事。

四、微服务架构与传统单体架构的对比

单块架构应用：功能集中，代码和数据中心化，一个发布包部署后运行在同一个进程中的应用程序

单块架构的优势：

1）易于开发

2）易于测试

3）易于部署

4）易于水平伸缩(所有的功能都会打成一个包，在集群中新建一个节点，配置好节点的运行环境，复制软件包到响应的位置，保证负载均衡的分发策略有效分发到当前节点即可)

面临的挑战：

1）维护成本增加，代码量过大，不利于快速定位问题

2）持续交付周期长：构建 部署和测试的实际都会随着代码量的增加而成倍的增长

3）新人培养周期长：业务熟悉和环境部署都会有很大的难度

4）技术选型成本高：较大规模的系统，最初的选型会影响新技术的使用

5）可扩展性差：

  a 垂直扩展：增加服务器

  b 水平扩展：在集群中添加节点，使用负载均衡(若应用有一部分是需要内存密集型缓存大量数据，有一部分是需要CPU密集型，需要进行大量运算，那么每次扩展新的节点都需要足够的内存和CPU来满足需求)

6）构建全功能团队难：会出现功能的扩展需要跨团队沟通

微服务架构：

是一种架构模式，提倡将单一应用程序划分为一组小的服务，服务之间相互协调，相互配合，为用户提供最终价值，每个服务运行在独立的进程中，服务间采用轻量级的通信机制相互沟通(通常是基于http的restful api)，每个服务围绕自己的具体业务构建，可以独立部署，应尽量避免统一的，集中式的服务管理机制，对于具体的一个服务而言，应根据业务上下文，选择合适的语言 工具来进行构建，也就是：

通过对特定业务领域的分析和建模，将复杂的应用分解成小而专一的，耦合度低并且高度自治的一组服务，每一个服务都是一个小的应用

编译语言有良好的语言类型约束和编译期检查，但代码比较复杂

动态语言灵活性高，运行时可以改变其内存结构，无类型检查，无需写交较多类型相关的代码，但不方便调试

开发 测试 部署完全独立，语言独立

服务与服务之间相互独立，相互隔离

在单块架构中，应用程序的代码虽然被分成逻辑上的3层或者4层，但并非物理上的分层，所有的功能经过编译，打包，部署后还是会运行在同一个进程中，这就意味着对应用部署时必须停掉正在运行的服务，部署完成后再重新启动进程，无法独立部署

一般为了代码的重用性，会把重复的代码封装成组件(可独立升级，独立替换掉的部分)，传统架构中，通常是共享库，比如jar包或者是win下的dll等

但在微服务架构中，应用程序由多个服务组成，每个服务都是一个具有高度自治的独立业务实体，每个服务可以运行在一个独立的进程中，不同的服务可以轻易的部署到不同的主机上

理论上可以把不同的服务部署到同一个节点上，运行到不同的进程里，但是不推荐，既然是微服务，最好保证高度的自治性和隔离性，运行在同一个节点上，虽然省去了节点的开销，却增加了部署和扩展的复杂度，部署某一个新的服务时，可能会对该节点的原有服务造成影响，另外随着业务的发展，可能某些业务需要水平扩容，有些不需要，如果不能有效的组织服务，可能会给服务的水平扩容带来不必要的麻烦。