微服务

CI Weekly 围绕『 软件工程效率提升』 进行一系列技术内容分享，包括国内外持续集成、持续交付，持续部署、自动化测试、 DevOps 等实践教程、工具与资源，以及一些工程师文化相关的程序员 Tips 。同步于 flow.ci Blog、微信公众号、 官方微博 ， 知乎专栏 ， 简书 ，欢迎关注或投稿:) 上周，我们对 flow.ci 做了比较多的功能优化: 1、iOS 项目持续集成 iOS 项目支持 Carthage 依赖管理； 去除 iOS 项目中自动管理证书设置，防止 Xcode8 编译失； 解决 xcodebuild 接口返回数据问题； 2、代码仓库授权 代码仓库重新授权优化； 分支处理优化； 3、其他 增加在线问题反馈； Build 邮件问题 Bug 修复； 任务的 Step 状态显示问题修复； 详细见 更新日志 ，有问题可通过「在线消息」或去 Gitter群 反馈 :) 本期 CI Weekly 整理了关于微服务架构下的持续部署与交付、自动化测试、DevOps相关的技术实践，欢迎提出意见~ 『 Docker/ 持续集成/持续部署相关实践 』 微服务架构下的开发部署实践 本文将从以下几个方面简要说明微服务架构项目的实践经验：架构选型、开发测试环境下的相关工具支持、人员分工及开发部署流程、相关设计及注意事项。 （via : 知乎： 无为2016 ）

这是关于使用微服务架构创建应用系列的第四篇文章。 第一篇 介绍了微服务架构的模式，讨论了使用微服务架构的优缺点。 第二 和 第三篇 描述了微服务架构内部的通讯机制。这篇文章中，我们将会探讨服务发现相关问题。 为什么要使用服务发现? 设想一下，我们正在写代码使用了提供REST API或者Thrift API的服务，为了完成一次服务请求，代码需要知道服务实例的网络位置（IP地址和端口）。传统应用都运行在物理硬件上，服务实例的网络位置都是相对固定的。例如，代码可以从一个经常变更的配置文件中读取网络位置。 而对于一个现代的，基于云微服务的应用来说，这却是一个很麻烦的问题。其架构如图所示： 服务实例的网络位置都是动态分配的，而且因为扩展、失效和升级等需求，服务实例会经常动态改变，因此，客户端代码需要使用一种更加复杂的服务发现机制。 目前有两大类服务发现模式： 客户端发现 和 服务端发现 。 我们先来来讨论一下客户端发现。 客户端发现模式 当使用 客户端发现模式 时，客户端负责决定相应服务实例的网络位置，并且对请求实现负载均衡。客户端从一个服务注册服务中查询，其中是所有可用服务实例的库。客户端使用负载均衡算法从多个服务实例中选择出一个，然后发出请求。 下图显示的是这种模式的架构图： 服务实例的网络位置是在启动时注册到服务注册表中，并且在服务终止时从注册表中删除

在微服务架构中，业务会拆分成一个独立的服务，服务与服务之间基于http restful进行通信。Spring Cloud有两种服务调用方式，一种是Ribbon+restTemplate，另一种是Feign。 1 Ribbon+restTemplate 1.1 Ribbon介绍 Spring Cloud Ribbon是基于HTTP和TCP的客户端负载均衡工具，基于Netflix Ribbon实现。通过Spring Cloud封装，可以方便地将面向服务的REST模板请求自动转换成客户端负载均衡的服务调用。包括下面的Feign调用，也是基于Ribbon实现的。 基于Spring Cloud Ribbon的封装，使用客户端负载均衡调用服务非常简单，只需实现两步： ①服务提供者只需启动多个服务实例并注册到一个注册中心或多个相关联的服务注册中心。 ②服务消费者直接通过调用被@LoadBalanced注解（开启客户端负载均衡）的RestTemplate实现面向服务的接口调用。 1.2 测试Ribbon+restTemplate方式调用 1.2.1创建服务提供方（Eureka Client） 基于之前工程，创建新模块ribbon-service，选择Spring Initializr->Cloud Discovery->Eureka Discovery，并添加以下依赖： <dependencies

一、逃离单体系统，拥抱微服务？ 单体系统和微服务的区别在于，一个单体系统是一个大而全的功能集合，每个服务器运行的是这个应用的完整服务。而微服务是独立自治的功能模块，它是生态系统中的一部分，和其他微服务是共生关系。现在，业界对单体系统和微服务的普遍观点是：单体系统非常容易开发、测试、部署，但是单体系统面对的问题也很多，例如开发效率变低、维护成本增加、部署影响变大、可扩展性较差、技术选型成本高，而引入了微服务可以实现每个微服务易于开发与维护，便于沟通与协作，很适合小团队敏捷开发与持续交付；每个微服务职责单一，高内聚、低耦合。同时，每个微服务能够独立开发、独立运行、独立部署；每个微服务之间是独立的，如果某个服务部署或者宕机，只会影响到当前服务，而不会对整个业务系统产生影响；每个微服务可以随着系统规模的不断扩大，面对海量用户和高并发，独立做水平扩展与垂直扩展；每个微服务可以使用不同的编程语言以及不同的存储技术，使得我们更容易尝试新的技术。此外，对单个服务进行业务重构，也不会面临很大的业务负担与技术债券。 笔者对微服务系统的观点是，我们从单体系统向微服务系统改造的过程中，需要认真思考什么阶段使用微服务。微服务不是银弹，它对于设计和运维难度提出了更高的要求，同时也带来了一些技术的复杂度。因此，我们需要思考与解决分布式的复杂性、数据的一致性、服务的管理与运维、服务的自动化部署等解决方案。事实上

前言 上一篇 基于docker部署的微服务架构（五）： docker环境下的zookeeper和kafka部署 中，已经成功部署了 kafka 环境，现在我们要改造之前的项目，使用 log4j2 的 kafka appender 把日志统一输出到 kafka 中。 修改日志系统 spring boot 默认使用 logback 作为日志工具，这里需要作出修改。 以 service-registry-demo 为例，其他项目做相同的修改。 修改 pom.xml 文件，去掉默认的日志依赖，并引入 log4j2 ： <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter</artifactId> <exclusions> <exclusion> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-logging</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring

kafka简单介绍 Kafka 是 LinkedIn 开源的一种高吞吐量的分布式发布订阅消息系统，kafka的诞生就是为了处理海量日志数据，所以kafka处理消息的效率非常高，即使是非常普通的硬件也可以支持每秒数百万的消息。 kafka 天然支持集群负载均衡，使用 zookeeper 进行分布式协调管理。不支持事务，有一定概率丢失消息。 kafka 的特点，决定了使用场景：日志中间件。 下载docker镜像 zookeeker: docker pull zookeeper:latest kafka: docker pull wurstmeister/kafka:latest 创建并启动容器 先启动zookeeper: docker run -d --name zookeeper --publish 2181:2181 \ --volume /etc/localtime:/etc/localtime \ zookeeper:latest zookeeper启动完成后再启动kafka: docker run -d --name kafka --publish 9092:9092 \ --link zookeeper \ --env KAFKA_ZOOKEEPER_CONNECT=zookeeper:2181 \ --env KAFKA_ADVERTISED_HOST_NAME

1 Hystrix介绍 Spring Cloud Hystrix是分布式系统处理超时和错误的机制，如下图所示，分布式系统中某个用户请求依赖A、H、I、P服务。 当此请求并发超过50的时候，服务I处理速度变慢，但是服务I还是被调用。 大量请求会阻塞在Tomcat服务器上，影响其它整个服务。在复杂的分布式架构的应用程序有很多的依赖，都会不可避免地在某些时候失败。高并发的依赖失败时如果没有隔离措施，当前应用服务就有被拖垮的风险。 Spring Cloud Hystrix就是隔离措施的一种实现，可以设置在某种超时或者失败情形下断开依赖调用或者返回指定逻辑，从而提高分布式系统的稳定性。 2 测试Hystrix 2.1 Ribbon使用Hystrix 2.1.1改造ribbon-service模块，在pom.xml文件中添加spring-cloud-starter-hystrix起步依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-hystrix</artifactId> </dependency> 2.1.2 在启动类上添加@EnableHystrix注解开启Hystrix断路器功能 @SpringBootApplication

原文同步至 http://waylau.com/ahout-microservices/ 自 2014 年始，Microservices（微服务）一词越来越火爆，不谈 Microservices 彷佛就 out 了。那么什么是 Microservices？Microservices 架构与传统的架构有什么区别？何时应该采用 Microservices？如何构建 Microservices？ 本文，就针对上述提到的问题，来简单介绍下 Microservices。 什么是 Microservices 微服务的诞生并非偶然: 领域驱动设计 指导我们如何分析并模型化复杂的业务； 敏捷方法论 帮助我们消除浪费，快速反馈； 持续交付 促使我们构建更快、更可靠、更频繁的软件部署和交付能力；虚拟化和基础设施自动化(Infrastructure As Code)则帮助我们简化环境的创建、安装； DevOps 文化的流行以及特性团队的出现，使得小团队更加全功能化。这些都是推动微服务诞生的重要因素。 实际上，业界对于微服务本身并没有一个严格的定义。James Lewis 和 Martin Fowler 对 Microservices 架构做了如下定义： 简言之，Microservices 架构风格就像是把小的服务开发成单一应用的形式， 运行在其自己的进程中，并采用轻量级的机制进行通信（一般是 HTTP

微服务治理背景，服务消费者A需要通过注册中心查询服务提供者B的地址，然后发起调用，可能会发送如下情况： 　　注册中心宕机 　　服务提供者B由节点宕机 　　服务消费者A和注册中心之间的网络不通 　　服务提供者B和注册中心之间的网络不通 　　服务消费者A和服务提供者B之间的网络不通 　　服务提供者B有些节点性能变慢 　　服务提供者B短时间内出现问题 对此，我们需要相应的服务治理手段。 　　 　　节点管理 　　服务调用失败，一般由两类原因引起，一类时服务提供者自身出现问题，如服务器宕机、进程意外退出等；一类时网络问题，如服务提供者、注册中心、服务消费者这三者任意两者之间的网络出现问题。主要有如下两种节点管理手段： 　　1、注册中心主动摘除机制 　　要求服务提供者定时向注册中心汇报心跳，注册中心根据服务提供者节点最近一次汇报心跳的时间与上一次汇报心跳时间作比较，如果超出一定时间，就认为服务提供者出现问题，继而把节点从服务列表中摘除，并把最近的可用服务列表推送给服务消费者。 　　2、服务消费者摘除机制 　　虽然注册中心主动摘除机制可以解决服务提供者节点异常的问题，但如果是因为注册中心与服务提供者之间的网络出现异常，最坏的情况是注册中心会把服务节点全部摘除，导致服务消费者没有可用的服务节点调用，但其实这时候服务提供者本身是正常的。所以，将存活探测机制用在服务消费者这一端更合理

Jhipster快速入门 核心技术栈 (TODO) 这里是列表文本环境设置 安装Jhipster 配置Eclipse/Intellij (TODO) 容器编排 (TODO) Jhipster核心任务 使用Jhipster微服务架构 创建项目 创建entity (TODO) 创建service (TODO) 创建DTOs (TODO) 管理关联关系 (TODO) 国际化 (TODO) 更新项目 (TODO) 可定制模块 给应用程序添加安全机制 使用Elasticsearch (TODO) 使用Websockets (TODO) 使用Oracle (TODO) 使用MongoDB (TODO) 使用Cassandra (TODO) 开发环境 在开发环境中使用Jhipster (TODO) 管理配置文件 (TODO) 使用AngularJS (TODO) 定制Bootstrap (TODO) 测试和Q&A 运行测试 (TODO) 代码质量监测 (TODO) 代持续集成 (TODO) 生产环境 使用在生产环境 (TODO) 指标监测 (TODO) 部署到Cloud Foundry (TODO) 部署到Heroku (TODO) 部署到AWS (TODO) 模块 模块市场 (TODO) 如何创建一个模块 (TODO) 工具 Jhipster实体语言 (TODO)