女朋友：你再深一点，这还不够，你把微服务给我讲仔细了再睡

前言

身为一名积极好学的前端女朋友还是会经常问我，微服务那么多理念，你跟我讲完，我就忘了，可以再给我讲讲它的思想到底是啷个回事嘛～看在她这么刻苦奋进的情况下，加之我们公司也做了许多微服务的项目，对此还算有所研究，今天就深层次的讲讲微服务吧！

本文来源：博客园

本文作者：浅羽技术

原文链接：
https://www.cnblogs.com/qianyueric/p/14548566.html

作者微信公众号：「 浅羽的IT小屋 」

 

单体架构

概念

单体架构也称之为单体系统或者是单体应用。就是一种把系统中所有的功能、模块耦合在一个应用中的架构方式。

特点

单体架构的特点主要有：

1. 打包成一个独立的单元(导成一个唯一的jar包或者是war包)

2. 以一个进程的方式来运行

 

单体架构

优点

易于开发： 开发方式简单，IDE 支持好，方便运行和调试。

易于测试： 所有功能运行在一个进程中，一旦进程启动，便可以进行系统测试。

易于部署： 只需要将打好的一个软件包发布到服务器即可。

易于水平伸缩： 只需要创建一个服务器节点，配置好运行时环境，再将软件包发布到新服务器节点即可运行程序（当然也需要采取分发策略保证请求能有效地分发到新节点）。

缺点

维护成本大： 当应用程序的功能越来越多、团队越来越大时，沟通成本、管理成本显著增加；当出现 bug 时，可能引起 bug 的原因组合越来越多，导致分析、定位和修复的成本增加；并且在对全局功能缺乏深度理解的情况下，容易在修复 bug 时引入新的 bug。

持续交付周期长： 构建和部署时间会随着功能的增多而增加，任何细微的修改都会触发部署流水线。

新人培养周期长： 新成员了解背景、熟悉业务和配置环境的时间越来越长。

技术选型成本高： 单块架构倾向于采用统一的技术平台或方案来解决所有问题，如果后续想引入新的技术或框架，成本和风险都很大。

可扩展性差： 随着功能的增加，垂直扩展的成本将会越来越大；而对于水平扩展而言，因为所有代码都运行在同一个进程，没办法做到针对应用程序的部分功能做独立的扩展

采用过时的单体架构的话，就会使得公司雇佣有潜力的开发者很困难，应用无法扩展，可靠性很低，那么我们再来看看微服务架构是怎样的呢？

微服务架构

概念

微服务是一种架构风格。一个大型的复杂软件应用，由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并且能够很好的完成该任务。

 

架构核心

核心部分

网关集群：数据的聚合、实现对接入客户端的身份认证、防报文重放与防数据篡改、功能调用的业务鉴权、响应数据的脱敏、流量与并发控制等。

业务集群：一般情况下移动端访问和浏览器访问的网关需要隔离，防止业务耦合。

Local Cache：由于客户端访问业务可能需要调用多个服务聚合，所以本地缓存有效地降低了服务调用的频次，同时也提示了访问速度。本地缓存一般使用自动过期方式，业务场景中允许有一定的数据延时。

服务层：原子服务层，实现基础的增删改查功能，如果需要依赖其他服务需要在 Service 层主动调用。

Remote Cache：访问 DB 前置一层分布式缓存，减少 DB 交互次数，提升系统的TPS。

DAL：数据访问层，如果单表数据量过大则需要通过 DAL 层做数据的分库分表处理。

MQ：消息队列用来解耦服务之间的依赖，异步调用可以通过 MQ 的方式来执行。

数据库主从：服务化过程中必经的阶段，用来提升系统的 TPS

架构

常见的架构有：

1. 客户端与服务端的

2. 基于组件模型的架构（EJB）

3. 分层架构(MVC)

4. 面向服务架构(SOA)

特点

1. 系统是由多个服务构成

2. 每个服务可以单独独立部署

3. 每个服务之间是松耦合的。服务内部是高内聚的，外部是低耦合的。高内聚就是每个服务只关注完成一个功能。

优点

边界清晰：比如说一个电商平台，我们以前是部署在一台服务器上，所有的代码打成一个war包。现在，我们可以给它拆分开：用户服务，积分服务，支付服务，仓储服务，信息服务，地图服务等等，每一个微服务只关注一个特定的业务功能，这样的话开发和维护单个服务都比较简单，因为它的边界足够清晰，业务也足够清晰，用户服务，只做好用户的事情就好了，相较于之前的大而全的单体服而言，每个微服务的代码量也比较少。

效率高：单体服务随着代码量变得越来越多，比如说百万行级别的代码，仅仅编译一次应用可能就需要花费很久，但是现在，如果一个地方有问题，比如说支付模块有问题，只需要单独修改支付模块，修改完支付模块之后，单独测试支付功能，单独部署支付模块就可以了，而不会影响整体的部署速度。

技术栈不受限制：每一个服务可以使用不同的技术栈来实现，由于不同的服务之间是通过restful API来通信的，所以每个服务可以使用不同的技术框架，使用不同的存储库来实现;

拓展性更强：随着业务的发展，用户量变得越来越多，或者说订单量猛增，这时我们可以专门去优化这个订单服务，给这个订单服务提供更高配置的机器，而其他并没有遇到瓶颈的业务，比如说短信服务，我们可以暂时不用动。

缺