一篇文章带你全面了解微服务

前言（废话，可以略过）

由CSDN规定要2000个字以上才能使用推荐卡，但我记录的文档都是以精简为主，根本挤不出2000个字呀，于是我只好将8篇文档合为一篇来进行发表，顺便也表达一下自己的观点，为什么一些书籍文档总是表达的特别多，让人找不到重点在哪，特别是国外的书籍，好了，废话不多，开始表演

1 微服务架构（MSA）简介

特征
系统由两个及以上组件组成，组件提供服务（组件即服务）
组件可以使用任何语言来进行开发
组件自己享有自己的数据库
组件可独立部署
系统有自动化测试
单个组件的故障不会拖垮整个应用

微服务架构的基础
首先进行架构设计，将系统分为恰到好处的独立组件，由各个团队开发这些组件

微服务的优势
微服务架构解耦了各个组件之间的依赖，一个组件的开发不需要去了解另一个组件的设计，使开发变得容易
微服务组件较小，上手开放比较块
微服务组件的开发一般12人，小至1人，沟通容易

2 发现服务与API网关

发现服务
服务A需要向服务B发送请求，那么B的ip地址是多少呢？
这里引入了发现服务，发现服务保存了A、B的地址

服务注册
发现服务如何知道服务A、B的地址？如下有两种服务注册方式
自注册：
服务A、B启动时，自动向发现服务注册其地址，当服务状态改变时，自动通知给发现服务

第三方注册：
服务A、B启动时，自动向发现服务注册其地址，发现服务新起一个进程，监控所有以注册服务的状态

服务调用
A需要向服务B发送请求，如何发送？
客户端发现：
A访问发现服务，获取B的地址，然后向B的地址发送

服务端发现：
这里新加了一个中间服务，用于服务到服务之间的调用
A将请求发送给中间服务，中间服务从发现服务获取B的地址，中间服务调用B

Api网关
一般客户端（如：浏览器页面）多需要从多个服务获取数据，但客户端并不知道服务的地址
Api网关主要解决客户端到服务的调用问题
客户端只需调用Api网关，Api网关从发现服务获取服务的地址，然后调用服务
职责：
请求转发（如：/abc开头的URL发送给服务A，/def开头的发送给服务B）
验证权限
均衡负载
断路器（某个服务调用的失败此时超过设定的值，则一定时间内不在对该服务进行调用）

3 微服务端点之间的通信

一个业务需要调用服务A、B、C才能完成，那么如何调用A、B、C？

编制与编排
编制
编制模式使用一个中间服务调用服务A、B、C完成业务

编排
编排模式，只需调用服务A，服务A完成或执行到某个位置时广播，B收到广播后开始执行，同理C

同步和异步通信
同步
同步用于执行上有顺序的服务，或一个服务需要另一个服务的响应数据
如：服务A执行完，告知服务B，服务B执行完，告知服务C
注：同步方式使服务之间产生耦合

异步
异步方式下，某个服务完成，直接广播消息，另一个服务收到消息后，就会开始执行
如：服务A完成，广播消息，服务B收到消息，开始执行，同理C
注：异步方式下，服务之间不在关系对方是否存在，而只关系消息，解决了服务之间的耦合

4 微服务安全

安全架构
如果我们的服务分散在网络中，那么我们的安全架构可能如下：

如果我们的服务聚集在局域网中，那么我们的安全架构可能如下：

技术的选择
一般使用OpenId进行认证，OAuth2进行授权，使用JWT格式的Token
既然提到了OAuth2认证，那就分清楚OAuth2认证中的 授权服务器、资源服务器、客户端

授权服务器：即我们的认证服务器
资源服务器：服务1、2、3
客户端：上述中我们并没有画出来，客户端就是我们的前端

笔者推荐使用的OAuth授权方式为Implicit（隐式认证）

5 高效的数据模型

数据库
微服务推荐每个服务使用一个数据库，这样就会涉及到多个数据库的事务同步问题
使用Saga事务模式（CQRS Saga 链接）来处理多个数据库的事务

数据模型
使用DDD（领域驱动设计）来设计数据模型（教程链接）
使用上下文区分服务
避免共享数据

从单体应用更变为微服务逐步迁移数据模型
使用视图：
如我们添加了模型A，模型A的数据在表A、B、C中保存，如果我们修改数据库表，那可能会肯复杂，最好的方法是添加视图A，模型A映射到视图A

6 微服务测试

测试流程
单元测试
集成测试
服务测试
契约测试
端到端测试

单元测试
单元测试对组件内类的方法进行测试，根据方法的返回结果与预期的结果进行比较判断
单元测试由开发人员进行编写

集成测试
继承测试是将各个组件组合起来，进行测试
继承测试主要测试组件之间的接口
继承测试由开发人员组成起来的测试小组进行测试
如：
系统由ABCDEFG模块组成

测试如下

1.为A编写测试模块Sb，Sc，测试A调用BC模块的接口
2.加入B，为B编写测试模块Sd，Se，测试B调用DE模块的接口
3.后面同理…

组件（服务）测试
组件测试将服务部署到网络中，服务需要用到的数据库和需要调用的其他服务均由模拟服务器进行模拟（如：需要测试的服务A调用服务B期望返回数据“ABC”，那么我们直接返回“ABC”即可）

契约测试
什么鬼测试

端到端测试
测试整个应用，不使用任何模拟，站在用户的角度进行测试

7 微服务部署

持续继承（CI）和持续部署（CD）
持续继承：
团队的成员不断的将代码进行合并，并进行单元测试，至少一天一次

持续部署：
对集成的代码进行测试（如：集成测试，功能测试等），然后发布到域生产环境中进行验收测试，然后发布到生产环境中，整个过程都是自动化的

CI、CD工具
Jenkins可以完成持续继承和持续部署，帮助我们自动化的发布应用

Docker
Docker 是一个开源的应用容器引擎，容器非常适合持续集成和持续交付（CI / CD）工作流程，我们的微服务推荐发布的Docker中

8 监控与扩展

监控原则
监控只发送重要的信息
监控门前流量（即外部发送的请求）

通过日志记录帮助监控
在一个请求链上记录相同的请求ID到日志中，有助于日志查找

监控工具
如下工具能帮我们更好的监控系统
ELK：日志收集、搜索、展示工具
…

微服务系统扩展原则
通过复制服务组件扩展
通过将服务组件分解为更小的组件扩展

后言（？？？）

好吧，我坦白了，我的目的不是为了讲解微服务，上面的文章都是废话，以下才是正文

IceEmblemCMS
演示地址：http://www.iceemblem.cn/
账号/密码：admini/123456
Github：https://github.com/IceEmblem/IEManageSystem
目前CMS还处于开发阶段，bug 比较多，还请谅解

可视化编辑的CMS
与其他可视化 CMS 不同的是，IceEmblemCMS的组件具有自己的自定义配置和数据和执行逻辑，可以完成一系列功能，如图表，审核，评论，点赞等。IceEmblemCMS所有页面都是从空白页开始搭建，当然，你也可以导入现有的模板

独特的文章发表
IceEmblemCMS的文章发表机制与其他CMS不同，IceEmblemCMS的文章发表是在页面上进行操作的，而可以发表的内容则由组件决定（如：你添加了一个图表组件，那么发表文章的时候就会附带该组件的数据编辑）

正在集成移动App
是的，不是Web，是App，为了更便捷的操作，App的页面还是在浏览器上进行编辑，而这其中的差异我会想办法兼容

我的目的
明人不说暗话，我想要的的Star