微服务概述
SOA团队 2020-03-16
■ 微服务架构的概念
从上图可以看到，微服务架构的第一个重点，即业务系统本身的组件化和服务化，原来开发一个业务系统本身虽然分了组件和模块，但是本质还是紧耦合的，这关键的一个判断标准就是如果要将原有的业务系统按照模块分开部署到不同的进程里面并完成一个完整业务系统是不可能实现的。而对于微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用。这些小应用之间通过服务完成交互和集成。每个小应用从前端web ui，到控制层，逻辑层，数据库访问，数据库都完全是独立的一套。在这里我们不用组件而用小应用这个词更加合适，每个小应用除了完成自身本身的业务功能外，重点就是还需要消费外部其它应用暴露的服务，同时自身也将自身的能力朝外部发布为服务。
把这个核心搞清楚后，再来看下网上找到的对微服务架构的一些定义和阐述：
微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制，如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。而在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。
微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配，这种说法完全正确。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价。如果你阅读了Fowler的整篇文章，你会发现，其中的指导建议是非常实用的。在决定将所有组件组合到一起时，开发人员需要非常确信这些组件都会有所改变，并且规模也会发生变化。服务粒度越粗，就越难以符合规定原则。服务粒度越细，就越能够灵活地降低变化和负载所带来的影响。然而，利弊之间的权衡过程是非常复杂的，我们要在配置和资金模型的基础上考虑到基础设施的成本问题。
对于上面红色字体标注的两点，再强调下即：
● 首先对于应用本身暴露出来的服务，是和应用一起部署的，即服务本身并不单独部署，服务本身就是业务组件已有的接口能力发布和暴露出来的。了解到这点我们就看到一个关键，即我们在进行单个应用组件设计的时候，本身在组件内部就会有很大接口的设计和定义，那么这些接口我们可以根据和外部其它组件协同的需要将其发布为微服务，而如果不需要对外协同我们完全可以走内部API接口访问模式提高效率。
● 其次，微服务架构本身来源于互联网的思路，因此组件对外发布的服务强调了采用HTTP Rest API的方式来进行。这个也可以看到在互联网开放能力服务平台基本都采用了Http API的方式进行服务的发布和管理。从这个角度来说，组件朝外部暴露的能力才需要发布为微服务，其本身也是一种封装后的粗粒度服务。而不是将组件内部的所有业务规则和逻辑，组件本身的底层数据库CRUD操作全部朝外部发布。否则将极大的增加服务的梳理而难以进行整体服务管控和治理。
微服务的基本思想在于考虑围绕着业务领域组件来创建应用，这些应用可独立地进行开发、管理和加速。在分散的组件中使用微服务云架构和平台使部署、管理和服务功能交付变得更加简单。
■ 微服务架构的核心内容
■ 传统的单体应用
要讲微服务架构，一定涉及到微服务架构和传统单体应用的区别问题，先看下传统单体应用：
很多单体应用有时候也在强调是基于组件化和模块化的开始思路开发的，或者说是基于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网关能力的进一步增强。
远行科技
远行云商
