微服务

创建一个应用 快速开始 首先，创建你要存放应用的目录： mkdir myapplication 进入目录： cd myapplication/ 生成应用： yo jhipster 根据需求回答相应的问题，详细的问题在 下面部分 会提到. 当应用生成后，你可以通过 Maven ( ./mvnw on Linux/MacOS, mvnw.cmd on Windows) 或者 Gradle ( ./gradlew on Linux/MacOS, gradelw.bat on Windows) 启动应用。 你可以前往 Using JHipster in development 页获取更多信息。 你可以通过 http://localhost:8080 访问你的应用。 当生成应用时需要回答的问题 _一些问题的改变取决于你前面的选择。例如，如果你zhiq没有选择一个SQL数据库的话，你不需要配置一个 Hibernate 缓存。 你想创建什么类型的应用？ 你需要选择的应用依赖于你是否想选择微服务作为你的架构。关于微服务的详细描述在 available here ，如果你不确定，就选择默认的 “Monolithic application”。 你可以选择： 一体化应用：这是一个典型的，通用的应用。它容易使用和开发，是我们默认推荐的。 微服务应用：采用微服务的架构，这是其中一个服务实例。 微服务网关

摘要 微服务架构 vs 一体化架构 概览 JHipster 的API 网关 使用网关进行HTTP路由 安全 自动生成文档 请求速率限制 访问控制策略 JHipster 的注册中心 JHipster 注册中心概览 JHipster 注册中心的安全保障 在JHipster 上注册你的应用 创建微服务应用 为微服务应用生成实体对象 使用HazelCast做分布式缓存 不带数据库的微服务应用 使用 Docker Compose 使用JHipster Console 和ELK技术栈来监控服务 生产环境 部署到 Docker Swarm 部署到 CloudFoundry 部署到 Heroku 微服务架构 vs 一体化架构 使用 JHipster 生成应用时，第一个问题就是让你选择你要的生成的应用(目前有4个选项)，但实际上你是在两种架构风格里面做选择： 一体化架构，用来创建单独的一个应用，包含前端 AngularJS 代码和后端 spring boot 相关代码，项目中所有代码都在一个应用中。 微服务架构，进行了前后端分离，优点是它可以让你很容易的控制单个应用的规模，并处理好这些应用中一些简单细小的问题。 相对来说，一体化架构是比较容易上手，官网默认推荐这个，如果是刚接触 JHipstert，建议从这个入手，熟悉后，如果项目有要求，则再选择微服务架构应用。

　　在之前的章节，我们已经实现了配置服务器、注册服务器、微服务服务端，实现了服务注册与发现。这一章将实现微服务的客户端，以及联调、实现整个spring cloud框架核心应用。 　　本文属于《7天学会spring cloud系列》之五，涉及到的项目包括： 　　开源项目： http://git.oschina.net/zhou666/spring-cloud-7simple cloud-config-server：配置服务器 cloud-eureka-server：eureka注册服务器 cloud-simple-service：一个使用mybatis的数据库应用，服务端 cloud-simple-ui：webui客户端 　　我们先来看看如何实现webui客户端。在spring boot中，已经不推荐使用jsp，所以你如果使用jsp来实现webui端，将会很麻烦。这可能跟现在的开发主流偏重移动端有关，跟微服务有关，跟整个时代当前的技术需求有关。单纯以html来作为客户端，有很多好处，比如更利于使用高速缓存；使后台服务无状态话，更利于处理高并发；更利于页面作为服务，小服务组合成大服务等。 　　我们首选来创建webui应用，参考git cloud-simple-ui工程： 　　 这个应用包括前端html页面，还包括一个后台controller浅层。这是一个前端应用

目录 前言 一、微服务介绍 1.什么是微服务 微服务由来 为什么需要微服务？ 3.1 早期的单体架构带来的问题 3.2 微服务与单体架构区别 3.3 微服务与SOA区别 微服务本质 什么样的项目适合微服务 微服务折分与设计 6.1 微服务设计原则 微服务优势与缺点 7.1 特性 7.2 特点 7.3 缺点 微服务开发框架 Sprint cloud 和 Sprint boot区别 二、微服务实践先知 客户端如何访问这些服务？（API Gateway） 服务之间如何通信？（服务调用） 这么多服务怎么查找？（服务发现） 服务挂了怎么办？ 微服务需要考虑的问题 三、微服务重要部件 微服务基本能力 服务注册中心 2.1 zookeeper服务注册和发现 负载均衡 3.1 负载均衡的常见策略 容错 4.1 容错策略 熔断 限流和降级 SLA API网关 多级缓存 超时和重试 线程池隔离 降级和限流 网关监控和统计 前言 到底什么是微服务？为什么要用微服务？微服务主要来做一些什么？微服务有哪些优势？什么样的服务属于微服务？本文所有资料来源网络，我只是整理一下，总结一下。仅供参考。 一、微服务介绍 1.什么是微服务 在介绍微服务时，首先得先理解什么是微服务，顾名思义，微服务得从两个方面去理解，什么是"微"、什么是"服务"， 微，狭义来讲就是体积小、著名的"2 pizza 团队"很好的诠释了这一解释

前言 随着互联网在21世纪初被大规模接入，互联网由基于流量点击赢利的单方面信息发布的Web 1.0业务模式，转变为由用户主导而生成内容的Web 2.0业务模式。因此，互联网应用系统所需处理的访问量和数据量均疾速增长，后端技术架构也因此面临着巨大的挑战。 Web 2.0阶段的互联网后端架构大多经历了由All in One的单体式应用架构渐渐转为更加灵活的分布式应用架构的过程，互联网开发架构开始追求更高的质量和效率。 随着智能手机的出现以及4G标准的普及，互联网应用由PC端迅速转向更加自由的移动端。移动设备由于携带方便且便于定位，因此在出行、网络购物、支付等方面彻底改变了现代人的生活方式。在技术方面，为了应对更加庞大的集群规模，单纯的分布式系统已经难于驾驭， 因此技术圈开启了一个概念爆发的时代——SOA、DevOps、容器、CI/CD、微服务、Service Mesh等概念层出不穷，而Docker、Kubernetes、Mesos、Spring Cloud、gRPC、Istio等一系列产品的出现，标志着云时代已真正到来 。 本文（或者说本系列文章），是本人在阅读完 Sam Newman 的《微服务设计》一书之后，与其他的微服务设计相关文章、《从服务化到云原生》等书籍进行关联阅读后做的笔记总结。 目的是构建分布式、微服务、云原生方面的体系化的知识结构树。 希望巩固学习的同时能够帮助到你。

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 简单的说，微服务是架构设计方式，分布式是系统部署方式，两者概念不同 微服务是啥？ 这里不引用书本上的复杂概论了，简单来说微服务就是很小的服务，小到一个服务只对应一个单一的功能，只做一件事。这个服务可以单独部署运行，服务之间可以通过RPC来相互交互，每个微服务都是由独立的小团队开发，测试，部署，上线，负责它的整个生命周期。 微服务架构又是啥？ 在做架构设计的时候，先做逻辑架构，再做物理架构，当你拿到需求后，估算过最大用户量和并发量后，计算单个应用服务器能否满足需求，如果用户量只有几百人的小应用，单体应用就能搞定，即所有应用部署在一个应用服务器里，如果是很大用户量，且某些功能会被频繁访问，或者某些功能计算量很大，建议将应用拆解为多个子系统，各自负责各自功能，这就是微服务架构。 那么分布式又是啥？ 分布式服务顾名思义服务是分散部署在不同的机器上的，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是通过rpc来交互或者是webservice来交互的。逻辑架构设计完后就该做物理架构设计，系统应用部署在超过一台服务器或虚拟机上，且各分开部署的部分彼此通过各种通讯协议交互信息，就可算作分布式部署，生产环境下的微服务肯定是分布式部署的，分布式部署的应用不一定是微服务架构的，比如集群部署

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> ZooKeeper 是Apache基金会下的一个开源的、高可用的分布式应用协调服务。许多公司都把它用于服务发现。但在云环境中，面对设备及网络故障时的恢复能力是需要重点考虑的问题。因此，将应用部署在云上，就必须要预见到硬件故障、网络延迟以及网络分区等问题，进而构建出恢复能力强的系统。 Peter Kelley是个性化教育初创公司 Knewton 的一名软件工程师。 他认为 ，从根本上讲，把ZooKeeper用于服务发现是个错误的做法，理由如下： 在ZooKeeper中，网络分区中的客户端节点无法到达Quorum时，就会与ZooKeeper失去联系，从而也就无法使用其服务发现机制。因此，在用于服务发现时，ZooKeeper无法很好地处理网络分区问题。作为一个协调服务，这没问题。但对于服务发现来说，信息中可能包含错误要好于没有信息。虽然可以通过客户端缓存和其它技术弥补这种缺陷，像 Pinterest 和 Airbnb 等公司所做的那样，但这并不能从根本上解决问题，如果Quorum完全不可用，或者集群分区和客户端都恰好连接到了不属于这个Quorum但仍然健康的节点，那么客户端状态仍将丢失。 更重要地，上述做法的本质是试图用缓存提高一个一致性系统的可用性，即在一个CP系统之上构建AP系统，这根本就是错误的方法

接着上一篇博客： 第一步：提供一个服务实例出来：micro-provider(服务提供者)，可以单独的去部署到服务器上。 ①：建个SpringBoot的项目，需要的依赖如下： ②：配置下mybatis的数据源和相应的驼峰映射： ③：写相应的实体类： ④：写相应的Mapper接口，由于这个mapper是交给Spring容器控制和管理的，所以说在启动类上加一个扫描Mapper接口的注解，然后这个这个接口就会生产接口的代理实现类去交给Spring容器进行管理。 ⑤：在Mapper接口中写一个根据id查出用户信息的方法： ⑥：由于这个接口要形成映射的，由于现在写的是单表的操作，就不写xml了，直接用注解的方式来进行编写如下： 如果这里用@Autowired的话，它会在Spring容器中会检测是否会有这样的对象动态的已经添加到容器中。这个@Autowired标注的对象不像@Service一样标在类上就能识别。而，在启动类上用的MapperScaner用的注解是在运行的时候才能识别，所以说这里用@Resource注解来注入，@Resource注解不会去找，它相当于使用的是java的东西（import javax.annotation.Resource)。就和Spring不会挂钩，但是它也会去Spring容器中去找。这里会按类型装，不会按名称装。 @Resource注解和

微服务雏形得形成 首先大家看看四个图： 一、单体架构图 ： 这个图不是微服务内容的一个图，相当于它就是一个系统。这个系统包含了6个模块。 第一个是乘客：PASSENGER MANAGEMENT 第二个是出租车司机：DRIVER MANAGEMENT。 第三个是定位：TRIP MANAGEMENT 第四个是通知：BILLING。 第五个是跟踪：NOTIFICATION 第六个是身份认证：PAYMENTS。 下面的图就好比前身的滴滴打车的项目，最前期的一个图。滴滴刚开始做的时候也是一个单体的架构。并没有想到自己做那么大，只是一个单体的项目。单体的项目设计主要是它把所有的模块融入到一个系统 里面去进行实现。这么多的模块共享了一个数据库，针对现在滴滴打车，滴滴公司越来越大，用户的群体也越来越大。一个数据库肯定做不了。它必须在数据库这块做相应的集群，做相应的负载等等做一些相关的操作，现在的滴滴如果用一个数据库的话，做起来非常的困难，这就是 单体架构瓶颈的问题，在架构中我们是无法去解决它。 在往下面看的话：PASSENGER:是个乘客，DRIVER:是个司机，比如说乘客下了一个订单，然后这个司机和乘客调用的是同一个RESTAPI，通过rest方式提供的API。我知道这个API，就知道了调用哪个模块了。REST API没有任何的隐蔽性，针对于安全来说是无法做到的，这里没有提供任何网关的形式的

Eureka 客户端的服务注册 Eureka 客户端在运行时会向 Eureka 服务端发送周期性的心跳，Eureka 服务端利用客户端周期性的心跳续约请求来保证注册表的实时性。其中客户端会向服务端提供一个如果多久没有向服务端发送心跳请求，就不再维护这个客户端的时间阈值。 Eureka 客户端的服务拉取 在通常情况下服务提供者可能为多个实例，服务调用者在调用服务时通过一些特定的负载均衡算法来把请求转发到该服务调用者的实例上。Eureka 客户端也会定时向服务端获取最新的服务列表，如果想保证实时性更高的话需要修改其配置来实现。 Eureka 服务端的注册列表维护 当客户端心跳续约请求超过与服务端约定好的时间阈值之后，Eureka 服务端会将该客户端实例加入到待清理的一个列表中之后由定时器来清理。如果我们想让服务端的注册列表实时性更高一些除了需要修改客户端的配置也需要修改服务端清理定时器的配置。 Eureka 的自我保护机制 以下来自Netflix官方解释 原文链接 Eureka 客户尝试与同一区域的Eureka服务器通话。如果在与服务器交谈时出现问题，或者服务器不在同一区域中，则客户端将故障转移到其他区域中的服务器。 一旦服务器开始接收流量，服务器上执行的所有操作都会复制到服务器知道的所有对等节点。如果某个操作由于某种原因而失败，则该信息将与下一个在服务器之间复制的心跳同步。