到底什么是微服务架构？

一 了解分布式架构的发展过程

我们看一下常规的单体架构：

单体阶段：

1. 紧耦合
2. 系统复杂，牵一发动全局
3. 所有模块耦合在一个进程中
4. 完全封闭架构
5. 业务发展初期，快速满足客户需求

垂直拆分阶段：

垂直拆分阶段： 根据业务模块拆分，但是公用一个大型的数据库其存在一些问题：

1. 紧耦合
2. 垂直拆分系统，竖井式架构子系统之间没有直接关联重复造轮子∶ OS，DB， Midderware
3. 存在大量的重复代码拷贝
4. 完全封闭架构业务
5. 快速增长时，以应用系统为中心的架构模式

RPC通信阶段：

RPC通信阶段：

1. 紧耦合（共享分布式对象实现远程方法调用））
2. 系统交互采用RPC私有TCP协议（例如dubbo，grpc等）
3. 服务生产者消费者存在强代码依赖
4. 异构系统集成不友好
5. 高并发场景，性能比较好

RPC阶段看似合理，但是也存在一些很严重的问题：比如采用dubbo这种方式，需要严格知道调用对象的地址，端口或者是否存在provider，属于紧耦合并侵入式。

并且如果是异构系统，一个是java一个是go，涉及到两种语言对象的转换问题。

ESB服务总线:(ESB是一个收费的系统)：

ESB服务总线阶段

1. 松耦合
2. ESB消息总线技术实现异构系统集成集中式架构管理
3. 基于WebService技术，重量级的消息通讯机制
4. 业务功能重用，粒度粗
5. 智能管道哑终端
6. 面向服务架构，团队规模大时，集成异构系统，提供统一服务解决方案。

二 到底怎么才能算微服务架构

我们来看一个标准的微服务的示意图：

官方定义:

三 宜信落地的分布式架构体系

1. 业务集群向我们的注册中心注册当前自己的服务（eureka，nacos，cosul等）
2. 业务集群向配置中心拉去配置（apollo，nacos，config-map等）
3. api网关（请求路由，安全认证，过滤等等，基本所有的规则都可以在网关二次开发），sso单点登录模块进行用户信息
4. 基础服务（例如需要在凌晨或者指定时间进行结算等，文件类的基础服务，mq异步模块）
5. 看板（任务管理系统），监控系统（grafa，elk，premethus）
6. 自动构建服务