Oracle微服务架构设计应用系统

Posted 2021-04-14 甲骨文开发者社区

“微服务”是一个快速发展的主题，尽管它不是一个新的想法，“微服务”一词是2011年5月在威尼斯附近举办的软件架构师讲习班上由软件架构大师Martin Fowler提出来的，微服务架构风格是将一个单体的应用程序开发拆解为一组“小”的服务，这里所说的“小”是以业务边界区分的，而不是根据代码的多少来区分。每个服务都运行在一个单独的进程中，服务之间通过轻量级的机制进行通信，每个服务都可以通过全自动化的部署机制来独立总署微服务中的各个服务可以以多种语言来编写，每个服务都可以使用不同数据存储技术。简单地讲，微服务就是一些协同工作的小而自治的服务。

为什么需要微服务

通常会将微服务架构和整体架构进行比较。

上图是三种架构方式的应用，分别是传统的整体架构，整体式SOA架构，微服务架构。传统的整体式架构主要包括三个部分：一个展示层，一个数据存储层，通常是一个数据库，最后一部分是服务端的应用程序；整体式SOA的架构同样包括三个部分，与传统的整体式架构唯一的区别是根据业务功能把不同的服务端应用程序封装成了不同的服务或API。在这样的架构中，所有的请求都在一个进程中处理，而且水平扩展也很简单，只需要多添加几台部署了该服务的机器，之后在这些服务器的前边再部署一台负载均衡器就可以了。

整体式架构有以下几个问题：

1. 由于所有的业务逻辑都写在了一个应用服务中，因此只要对该服务进行任何修改，哪怕是一点改动，也需要编译打包部署整个应用；

2. 整体应用中有一个服务达到了瓶颈，只能通过扩展整个应用来水平扩展这个服务的处理能力；

3. 随着应用程序规模的增加，很难保证对于一个模块的修改不会影响其它模块。

微服务架构的好处：

1. 技术异构性。可以在不同的服务中使用最适合该服务的技术。

2. 弹性。可以通过将同样的实例运行在不同的机器上来降低功能完全不可用的概率。

3. 扩展。只对需要扩展的服务进行扩展。

4. 简化部署。各个服务的部署是独立的，可以更快地对特定部分的代码进行部署。

5. 与组织结构匹配。避免出现过大的代码库，从而获得理想的团队大小及生产力。

6. 可组合性。开放出更多接口供外部使用。

7. 对可替代性的优化。在需要时轻易重写服务或者删除不再使用的服务。

微服务架构的缺点：

1. 冗余的代码。不同服务内含有相同功能的，需要在两个服务中都编写相同的代码；

2. 复杂的运维。需要配备高功底的运维人员以及完善的运维系统；

3. 分布式事务处理。因为“分布”的厉害，需要更完整的补偿机制保证分布式事务的完整处理；

4. 微服务拆分。拆分的原则是根据业务拆分，定义微服务的边界，需要一个好的架构师结合业务和技术进行微服务颗粒度的定义。

微服务中的组件

• 服务注册与服务发现。服务注册形象地讲是将服务的IP、Port和URL注册到注册中心。服务发现简单来讲是根据服务的唯一标识，从注册中心获取指定服务所在的服务器列表。使用服务注册和服务发现就是实现了服务间的解耦。
  

• 健康检查。健康检查主要检查两方面是否处理正常状态：一是服务所在服务器的运行状态；一是服务本身的运行状态。健康检查的目的是为了在服务发现和服务路由的时候可以将服务的调用请求发送到处于健康状态的机器上，不至于使服务调用因为请求被发送到不健康的机器上而失败。

• 配置管理。配置管理主要做三件事。一件是在一个地方将服务集中管理；一件是实现服务的配置与代码分离，这样修改配置信息后不需要再编译、打包、部署整个服务；一件事是实现“热部署”。

• 服务通信。微服务间的调用协议可以使用TCP或HTTP。基于HTTP的代码要比基于TCP协议的代码好写得多。

• 服务路由。当一个请求发过来，通过服务发现和健康检查选出健康的服务器列表，从这些服务器中选出一台，将请求发送到这台服务器上去。

• 服务容错。服务容错指的是当服务集群中的一台机器宕机，也不会导致整个服务不可用，甚至不会因为级联失败导致多个服务不可用，形成雪崩。

• 日志系统。日志系统主要用于收集散落在各台机器上的日志，并提供高效的存储和查询方式，通过清晰易懂的界面进行结果展示，同时提供方便的分析功能。

• 全链路追踪系统。在微服务架构中，由于微服务比较多，通过需要多个服务彼此协作调用完成一个端到端的业务功能，这个时候产生了调用链，需要一个全链路追踪系统帮助理清服务之间的依赖关系，可以分析调用链信息。

• 计数监控系统。在微服务架构中，服务众多，需要对这些服务的一系列指标进行记录监控。通过这些监控的信息，调优服务，也可以对服务有一个实时的了解，在发生错误时，可以尽快地去处理。

• 文档输出。文档输出是将API接口文档化，通过编写代码的方式来自动展现出API接口的各种信息。

• 持续集成与持续部署系统。如果没有持续集成/持续部署系统，需要手动管理代码，控制版本，需要手动将代码打包，手动上传到服务器，手动关掉服务，手动启动。如果是Docker镜像部署，还需要手动将服务打成镜像，手动将镜像Push到仓库，手动从镜像仓库中Pull下来，手动将镜像运行起来。

• 服务网关。服务网关用于接收请求，并转发至后端的微服务中。在转发过程中，可以进行横向的过滤。在服务网关中可以增加公用的处理逻辑来处理所有微服务共有的需求。如编码转换，权限校验等。

• 服务编排。通过对单一微服务定义容器的大小，容器的配置，由服务编排来保障微服务的服务器数量、服务能力。

Oracle微服务技术架构

Oracle微服务架构全栈采用目前稳定运行并经过大量案例验证后的开源框架。

• 使用容器技术做为微服务的载体；

• 受管于Kubernetes进行服务编排，自动部署；

• 通过Istio进行服务的注册和发现；

• 采用Kafka进行流量的管理以及分布式消息的处理；

• 使用Kubernetes管理企业内部微服务与外界云应用市场的服务调用；

• 使用Zipkin、Vizceral、Prometheus进行服务的监控、全链路追踪；

• 使用Jekins、Wercker进行持续集成与持续部署；

• 使用API Registry、APIAry进行服务网关的管理。

Oracle微服务架构不是简单使用开源框架进行微服务架构的构建，而是在这些开源框架中进行了大量的封装和改造，一方面提供给使用者开箱即用的微服务的功能，使用者无需再为了组合这些开源框架而大伤脑筋，只需要使用Oracle提供的微服务架构的接口和工具就可以了；另一方面，Oracle对架构中的所有开源框架进行的功能方面的扩展，比如使用Kafka，不仅仅使用了Kafka的分布式特性，同时还增加了消息规则库、消息分发引擎等更适用于企业使用的功能。

作者简介

李相国，甲骨文PaaS专家团队资深咨询顾问，专注于云计算应用新特性。具有20+年IT行业从业经验，对于云计算等前沿创新有一定的研究，您可以通过[e-mail]，与他联系。

了解更多，敬请关注甲骨文开发者社区......