基于SpringCloud的微服务容器化实践

近几年&＃xff0c;互联网飞速发展的同时&＃xff0c;也推动了云计算、大数据、人工智能的快速落地&＃xff0c;数据本身价值也得到提升。互联网发展对应用开发提出了更高要求。首先数据采集的量级和效率提高&＃xff0c;传统的单体架构将出现瓶颈&＃xff0c;其次是数据联通性的需求&＃xff0c;对数据对接必须保证高性能、高安全、高标准。使用微服务架构恰好解决了大部分痛点。
本次主要介绍基于Spring Cloud构建微服务&＃xff0c;以及配套的DevOps思路&＃xff0c;并着重介绍在Docker容器里如何部署基于Spring Cloud的微服务。

1、基于Spring Cloud构建微服务

历史总是惊人的相似&＃xff0c;合久必分&＃xff0c;分久必合。我们经历了“合”&＃xff1a;单体架构&＃xff08;软&＃xff09;、计算能力超强的小型机&＃xff08;硬&＃xff09;到“分”&＃xff1a;分布式架构的转变&＃xff0c;后期可能会将分发挥到了极致&＃xff08;去中心化的分布式&＃xff0c;如区块链&＃xff09;&＃xff0c;最后很可能再经历“合”&＃xff1a;计算和存储能力超强的“智人”&＃xff08;集超级计算和存储一身的人工智能&＃xff09;。
单体架构也有自身优势&＃xff0c;这里不做详细介绍&＃xff0c;大家在做架构选型时可以根据公司组织架构和业务需求综合考虑。
Spring Cloud作为Java语言的微服务框架&＃xff0c;它依赖于Spring Boot&＃xff0c;是由Pivotal团队提供的全新Web框架。有快速开发、持续交付和容易部署等特点。Spring Cloud提供了开发分布式服务系统的一些常用组件&＃xff0c;例如服务注册和发现、配置中心、熔断器、智能路由、微代理、控制总线、全局锁、分布式会话等。
先看看我们使用的一个架构&＃xff1a;

• 服务发现中心&＃xff08;Service Discovery&＃xff09;&＃xff1a;服务注册与发现组件&＃xff08;选用Erueka&＃xff09;

• 监控面板&＃xff08;Monitor Dashboard&＃xff09;&＃xff1a;整合了熔断监控&＃xff08;选用Hystrix&＃xff09;、服务调用链路监控&＃xff08;选用Spring Cloud Sleuth&＃xff09;

• 日志分析面板&＃xff08;Logging Analyses&＃xff09;&＃xff1a;基于efk构建的日志采集系统

  服务网关&＃xff08;Edge Server&＃xff09;&＃xff1a;服务网关组件&＃xff08;Zuul & Spring Cloud Security&＃xff09;

• OAuth认证服务器&＃xff08;OAuth Authorization Server&＃xff09;&＃xff1a;授权认证模块&＃xff08;Spring Cloud security OAuth2&＃xff09;

• 配置服务器&＃xff08;Configuration Server&＃xff09;&＃xff1a;配置中心&＃xff08;Spring Cloud Config & Spring Cloud Bus&＃xff09;

2、基于微服务架构体系的DevOps思路

DevOps带来的不仅是技术挑战&＃xff0c;还受公司组织架构和文化影响&＃xff0c;这里是从技术角度去实现的思路。
先看两个微服务应用案例&＃xff1a;
案例1&＃xff1a;基于微服务架构的接口开发
平台主要提供Restful API服务&＃xff0c;服务方式多样&＃xff0c;其中一个最简单的案例流程如下&＃xff1a;

• 首先企业通过申请账号、密码和需要调用的API

• 平台针对申请企业创建可调用API的账号和密码&＃xff0c;并将该企业调用端IP加入服务白名单&＃xff0c;用户可在平台下载文档、SDK&＃xff0c;并进行测试

• 企业根据用户名、密码去获取token&＃xff0c;并在请求header中加入申请的token调用接口

案例2&＃xff1a;基于微服务架构的应用开发
Web应用开发采用前后端分离方式&＃xff0c;前端采用AngularJS&＃xff0c;后端仍是基于Spring Cloud的微服务&＃xff0c;整套系统部署到容器云实现CI/CD&＃xff0c;架构如下图所示&＃xff1a;

微服务引入增加了团队配合、测试、运维等后续一系列操作的复杂度&＃xff0c;必须考虑自动化&＃xff0c;因此需要有一套CI/ CD方案应对&＃xff1a;

大致流程&＃xff1a;

1. 研发完成本地开发和测试提交代码

2. 代码连同Dockerfile等构建文件一起push到GitLab&＃xff08;可以自己搭建&＃xff09;

3. 代码提交触发Jenkins自动构建

4. Jenkins调用单元测试、代码检查等测试任务&＃xff0c;如果测试通过自动构建Docker镜像

5. Jenkins将构建好的镜像推送到私有镜像仓库&＃xff08;自己搭建Harbor镜像库&＃xff09;

6. Jenkins调用容器管理平台&＃xff08;我们使用的Rancher&＃xff09;的接口进行升级

7. 容器管理平台拉取镜像完成部署&＃xff08;测试环境or生产环境&＃xff09;

说明&＃xff1a;这里我们不仅使用了Docker&＃xff0c;还选用容器编排工具构建了容器云平台&＃xff0c;以方便我们快速实现CI/CD。大家可以根据自己情况选择&＃xff0c;如Kubernetes、Rancher&＃xff08;Rancher 2.0以后底层使用的编排工具也是Kubernetes&＃xff09;等。

3、Spring Cloud基于Docker的实践

我们使用Docker&＃xff0c;主要因为以下4点&＃xff1a;

1. Docker提供一个简单、轻量的建模方式

2. Docker使团队职责的逻辑分离

3. 可以实现快速高效的开发生命周期

4. 团队使用面向服务的架构

   
   

以下介绍如何构建Docker镜像和配置细节。
1. 项目目录
Dockerfile及相关文件一般放到项目子目录&＃xff0c;由开发维护。这种方式对研发提出了更高的技能要求&＃xff0c;这也是近期全栈工程师比较火的一个原因。当然&＃xff0c;具体协作方式还是根据公司情况定。以下是我们的项目目录&＃xff1a;

2. 编写Dockerfile&＃xff08;供参考&＃xff09;
注&＃xff1a;配合自动化工具使用效果更好。

FROM harbor.jry.com/library/alpine-jdk-time:slim
ADD *.jar service.jar
COPY formFile /
ENTRYPOINT [ "sh", "-c", "java -jar service.jar" ]


3、模块配置

我们将Spring Cloud相关的配置放到了bootstrap.yml文件&＃xff0c;需要注意的配置如下&＃xff1a;

注意标红部分&＃xff0c;服务要以IP地址方式注册到注册中心&＃xff0c;否则注册中心无法做心跳检测&＃xff0c;因为容器之间默认无法通过hostname通信。我们也可以搭建内部DNS方式解决此问题。
服务发现中心建议配置成高可用&＃xff08;比如两个注册中心互相注册&＃xff09;&＃xff0c;也需要上图配置。
4、打包构建
这里截取了Jenkins里的打包及构建命令&＃xff1a;

1. 打包

   

2. 构建

   

5、容器启动配置&＃xff08;docker-compose.yml&＃xff09;

version: &＃39;2&＃39;
services:
  zipkin:
    image: harbor.jry.com/zipkin:v1.0.1
    environment:
      eureka.client.service-url.defaultZone: http://discovery:8761/eureka/
    stdin_open: true
    tty: true
     links:
    - discovery2:discovery
     volumes:
    - /data/log:/target/log
    ports:
    - 9411:9411/tcp


  service-config:
    image: harbor.jry.com/service-config:v1.0.1
    hostname: config
    environment:
      eureka.client.service-url.defaultZone: http://discovery:8761/eureka/
    stdin_open: true
    tty: true
    links:
    - discovery2:discovery
    volumes:
    - /data/log:/target/log
    ports:
    - 8889:8889/tcp


  service-monitor:
    image: harbor.jry.com/service-monitor:v1.0.1
    environment:
      eureka.client.service-url.defaultZone: http://discovery:8761/eureka/
    stdin_open: true
    tty: true
    links:
    - discovery1:discovery
    volumes:
    - /data/log:/target/log


  discovery2:
    image: harbor.jry.com/service-discovery
    environment:
      eureka.client.service-url.defaultZone: http://discovery:8761/eureka/
    stdin_open: true
    tty: true
    links:
    - discovery1:discovery
    volumes:
    - /data/log:/target/log
    ports:
    - 8762:8761/tcp


  discovery1:
    image: harbor.jry.com/service-discovery:v1.0.1
    environment:
      eureka.client.service-url.defaultZone: http://discovery:8761/eureka/
    stdin_open: true
    tty: true
    links:
    - discovery2:discovery
    volumes:
    - /data/log:/target/log


  daas-monitor:
    image: harbor.jry.com/daas-monitor:v1.0.1
    environment:
      eureka.client.service-url.defaultZone: http://discovery:8761/eureka/
    stdin_open: true
    tty: true
    links:
    - discovery1:discovery
    volumes:
    - /data/log:/target/log
    ports:
    - 9080:9080/tcp


  proxy-server:
    image: harbor.jry.com/service-proxy:v1.0.1
    environment:
      eureka.client.serviceUrl.defaultZone: http://discovery:8761/eureka/
    stdin_open: true
    links:
    - discovery1:discovery
    tty: true
    links:
    - oauth2-server:oauth
    volumes:
    - /data/log:/target/log
    ports:
    - 8111:8443/tcp


  oauth2-server:
    image: harbor.jry.com/oauth2-cg:v1.0.1
    environment:
      eureka.client.serviceUrl.defaultZone: http://discovery:8761/eureka/
    stdin_open: true
    links:
    - discovery2:discovery
    volumes:
    - /data/log:/target/log
    tty: true
    ports:
    - 9999:9999/tcp

说明&＃xff1a;

• Zipkin&＃xff1a;服务调用链路监控

• service-config&＃xff1a;配置中心服务

• service-monitor&＃xff1a;断路监控服务

• discovery1&＃xff0c; discovery2&＃xff1a;高可用的服务发现中心

• daas-monitor&＃xff1a;自研的监控面板&＃xff0c;整合其他监控服务

• proxy-server&＃xff1a;服务网关

• oauth2-server&＃xff1a;OAuth认证服务器

注&＃xff1a;

1. 虽然使用的配置文件&＃xff0c;但维护起来还是很麻烦&＃xff0c;所以建议使用编排工具&＃xff0c;一般会提供部分DevOps工具集。

2. 上述各服务模块可以根据实际情况启动多个相同容器&＃xff0c;以保证高可用。

3. 以上各服务模块做了磁盘映射&＃xff0c;主要为采集日志&＃xff0c;这里我们使用的EFK&＃xff0c;时间关系暂不展开。

Q&A

Q&＃xff1a;WSO2的API Manager会将所有流量都统一到他这里进出&＃xff0c;如何解决统一API网关的大流量问题&＃xff1f;A&＃xff1a;API Manager是可以拆开的&＃xff0c;分开部署&＃xff0c;比如调用你接口走网关模块&＃xff0c;可以做高可用。当然不拆开也可以做高可用&＃xff0c;前面加负载均衡。
Q&＃xff1a;Eureka在生产上的Kubernetes中是如何做到高可用和动态扩容的&＃xff1f;A &＃xff1a;好问题&＃xff0c;Eureka我们目前是指定数量&＃xff0c;可以结合脚本&＃xff08;或代码&＃xff09;做动态扩容和高可用。目前我们Hadoop就是结合代码做到的。
Q&＃xff1a;服务之间二阶段事务控制一般怎么做&＃xff1f;或者说有没有现成工具或代码&＃xff1f;服务间用http靠谱还是其他协议靠谱&＃xff1f;A&＃xff1a;这个网上有一些思路比如补偿的方式&＃xff0c;还有就是通过流数据库&＃xff08;Kafka&＃xff09;&＃xff0c;事件驱动的方式。我们目前正在尝试这种方式。

基于Kubernetes的DevOps实践培训

基于Kubernetes的DevOps实践培训将于2018年8月24日在北京开课&＃xff0c;3天时间带你系统掌握Kubernetes。本次培训包括&＃xff1a;容器特性、镜像、网络&＃xff1b;Kubernetes架构、核心组件、基本功能&＃xff1b;Kubernetes设计理念、架构设计、基本功能、常用对象、设计原则&＃xff1b;Kubernetes的数据库、运行时、网络、插件已经落地经验&＃xff1b;微服务架构、组件、监控方案等&＃xff0c;点击下方图片查看详情。