微服务架构简单讲清楚(1.11-1.14)

对于微服务架构，我前面也写了一些文章，感觉还是没有将其本质讲解的特别清楚。这几天对微服务架构进行了一些思考，并补充了一些图解，希望能把微服务架构的一些核心内容讲明白。

传统的单体应用

要讲微服务架构，一定涉及到微服务架构和传统单体应用的区别问题，先看下传统单体应用：



很多单体应用有时候也在强调是基于组件化和模块化的开始思路开发的，或者说是基于SOA架构开发，那从运行态和设计态分别来看的话可以看到。

从运行态的视角：

1. DB走HA或RAC集群，但是扩展性是大问题，很多应用后期即使走了RAC也无法解决性能问题。
2. 部署的是一个大WAR包，无法分模块独立分开部署。
3. WAR部署当前可以是物理机，也可以是虚拟机，但是WAR包偏重，很少直接部署到Docker容器的。
4. Application Server层的性能可以通过负载均衡方式进行水平扩展。

从设计态的视角：

1. DB本身是无法拆分的，各个模块的数据库，视图全在一个大的SID或Schema里面。
2. 模块之间的交互除了通过逻辑层外，还有些是直接通过DB层的跨表连接完成的。
3. 逻辑层的模块和模块之间往往是紧耦合的，相互间的调用随意，很多都是内部API或方法调用。

不管是从运行态还是设计态来看，传统的单体应用最大的问题就是各个组件和模块之间紧耦合，而这种耦合带来的问题就是扩展困难，升级和变更困难（模块间相互影响大）。

其次，传统单体应用面临的第二个问题是展现层和逻辑层的紧耦合，而实际在当前应用架构设计和开发中，可以看到需要同时满足电脑，平板，手机APP终端等多种前端展现和访问。而这种访问必须是支持分布式的接口服务访问模式。传统单体应用要做到这点也只有进行改造，比如再单独增加一个服务代理组件来发布服务。

传统单体应用到微服务架构

正是由于传统单体应用存在的一些问题，微服务架构提出了将传统单体应用打散为多个离散，自治的独立组件。这些组件你可以称呼它为微服务模块，这些微服务模块本身需要满足的就是从数据库，到逻辑层，到界面展现层都能够是独立的一套；微服务模块能够从需求，设计，开发，测试，部署上线和运维都相对独立。

这个思想本质仍然是SOA架构思想和组件化思想在业务系统内部应用的体现。基于以上思考，传统单体应用转变为微服务架构后如下图所示：




从运行态的视角：

1. 数据库在部署的时候是可物理拆分的，即不同微服务模块的数据库可以独立部署。
2. 微服务模块的应用组件包是独立部署的。
3. WAR包由于已经按模块拆分为多个，因此每个WAR包相对来说更加轻，而容易部署到类似Docker容器上。
4. 由于WAR包之间有接口交互和协同，需要增加微服务网关实现服务管理和治理。

从设计态的视角：

1. 数据库，逻辑层和界面展现在设计的时候就是完全相对独立的一套。
2. 逻辑层的各个组件之间只能通过Service API接口进行交互，微服务架构下推荐轻量Http Rest接口。
3. 逻辑层各个模块之间彻底实现松耦合。各个模块本身也更加轻量。

微服务架构的核心单元-微服务网关



在引入微服务架构后，最大的一个变化就是原来单个业务系统内部的各个模块之间需要通过分布式的服务接口进行调用和协同了，而不是简单的走内部的API调用。

那么对于复杂的各个模块间的点对点调用，就需要有一个类似ESB总线的中间件将这些接口服务统一管理起来，以实现对服务注册，安全，流控，日志审计，消息，代理和路由的统一管理。而这些转到微服务架构后即是由微服务网关来完成。

在这个意思上来看，微服务网关类似简化了的ESB，没有了ESB总线复杂的适配，协议转换，内容转换，数据映射，服务编排等功能。也可以说微服务网关是传统OSGI网关能力的进一步增强。