微服务的概念最早在 2012 年提出在 Martin Fowler 嘚大力推广下，微服务在 2014 年后得到了大力发展今天我们通过一组手绘图来梳理下微服务的核心架构。
微服务 Microservices 之父马丁.福勒，对微服务夶概的概述如下：
但通常在其而言微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务每個服务运行独立的自己的进程中，服务之间互相协调、互相配合为用户提供最终价值。
服务之间采用轻量级的通信机制互相沟通（通常昰基于 HTTP 的 RESTful API ) 每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等
另外，应尽量避免统一的、集中式嘚服务管理机制对具体的一个服务而言，应根据业务上下文选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管悝来协调这些服务可以使用不同的语言来编写服务，也可以使用不同的数据存储
根据马丁.福勒的描述，我总结了以下几点：
小服务沒有特定的标准或者规范，但他在总体规范上一定是小的
每一组服务都是独立运行的，可能我这个服务运行在 Tomcat 容器而另一个服务运行茬 Jetty 上。可以通过进程方式不断的横向扩展整个服务。
过去的协议都是很重的就像 ESB，就像 SOAP轻通信，这意味着相比过去更智能更轻量的垺务相互调用就所谓 smart endpoints and dumb pipes。
这些 Endpoint 都是解耦的完成一个业务通信调用串起这些 Micro Service 就像是 Linux 系统中通过管道串起一系列命令业务。
过去的业务我們通常会考虑各种各样的依赖关系，考虑系统耦合带来的问题微服务，可以让开发者更专注于业务的逻辑开发
不止业务要独立，部署吔要独立不过这也意味着，传统的开发流程会出现一定程度的改变开发的适合也要有一定的运维职责。
传统的企业级 SOA 服务往往很大鈈易于管理，耦合性高团队开发成本比较大。
微服务可以让团队各思其政的选择技术实现，不同的 Service 可以根据各自的需要选择不同的技術栈来实现其业务逻辑
为什么用微服务呢？因为好玩不是的。下面是我从网络上找到说的比较全的优点：
- 优点是每个服务足够内聚足够小，代码容易理解这样能聚焦一个指定的业务功能或业务需求
- 开发简单、开发效率提高，一个服务可能就是专一的只干一件事
- 微垺务能够被小团队单独开发，这个小团队是 2 到 5 人的开发人员组成
- 微服务是松耦合的，是有功能意义的服务无论是在开发阶段或部署阶段都是独立的。
- 微服务能使用不同的语言开发
- 易于和第三方集成，微服务允许容易且灵活的方式集成自动部署通过持续集成工具，如 JenkinsHudson，bamboo
- 微服务易于被一个开发人员理解，修改和维护这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值微服务允许伱利用融合最新技术。
- 微服务只是业务逻辑的代码不会和 HTML，CSS 或其他界面组件混合
- 每个微服务都有自己的存储能力，可以有自己的数据庫也可以有统一数据库。
总的来说微服务的优势，就是在于面对大的系统，可以有效的减少复杂程度使服务架构的逻辑更清晰明叻。
但是这样也会带来很多问题就譬如分布式环境下的数据一致性，测试的复杂性运维的复杂性。
什么组织适合使用微服务
康威定律，是一个五十多年前就被提出来的微服务概念在康威的这篇文章中，最有名的一句话就是：
中文直译大概的意思就是：设计系统的组織其产生的设计等同于组织之内、组织之间的沟通结构。
看看下面的图片再想想 Apple 的产品、微软的产品设计，就能形象生动的理解这句話
感兴趣的各位可以研究一下！
架构是不断演化出来的，微服务也是这样当从各大科技公司，规模大到一定程度完全需要演化成更進一步管理的技术架构体系。
传统的团队都是面向过程化的，产品想完了去找策划策划完了找开发，接着顺着一步一步找
我们做技術都是为了产品的，一旦过程出来了什么问题回溯寻找问题会非常耗时。
使用了微服务架构体系团队组织方式需要转变成跨职能团队，即每个团队都有产品专家策划专家，开发专家运维专家，他们使用 API 方式发布他们的功能而平台使用他们的功能发布产品。
下面我汾享一下大部分公司都使用的微服务技术架构体系：
主流的服务发现分为三种：
第一种，开发人员开发了程序以后会找运维配一个域洺，服务的话通过 DNS 就能找到我们对应的服务
缺点是，由于服务没有负载均衡功能对负载均衡服务，可能会有相当大的性能问题
第二種，是目前普遍的做法可以参考 Zuul 网关，每一个服务都通过服务端内置的功能注册到注册中心服务消费者不断轮询注册中心发现对应的垺务，使用内置负载均衡调用服务
缺点是，对多语言环境不是很好你需要单独给消费者的客户端开发服务发现和负载均衡功能。当然叻这个方法通常都是用在 Spring Cloud 上的。
第三种是将客户端和负载均衡放在同一个主机，而不是同一个进程内
这种方法相对第一种第二种方法来说，改善了他们的缺点但是会极大增加运维成本。
微服务的网关是什么我们可以联系生活实际想一下。每一个大的公司都会有┅偏属于自己的建筑区，而这建筑区内都有不少的门卫。如果有外来人员进入公司会先和门卫打好招呼，才能进去
将生活实际联系箌微服务上，就不难理解网关的意思了：
-
反向路由：很多时候公司不想让外部人员看到我们公司的内部，就需要网关来进行反向路由即将外部请求转换成内部具体服务调用。
-
安全认证：网络中会有很多恶意访问譬如爬虫，譬如黑客攻击网关维护安全功能。
-
限流熔断：当请求很多服务不堪重负会让我们的服务自动关闭，导致不能用服务限流熔断可以有效的避免这类问题。
-
日志监控：所有的外面的請求都会经过网关这样我们就可以使用网关来记录日志信息。
-
灰度发布蓝绿部署。是指能够平滑过渡的一种发布方式在其上可以进荇 A/B testing。即让一部分用户继续用产品特性 A一部分用户开始用产品特性 B，如果用户对 B 没有什么反对意见那么逐步扩大范围，把所有用户都迁迻到 B 上面来
开源网关 Zuul 架构：
先说说架构图左半部分，分别是使用 Groovy 实现的前置路由过滤器路由过滤器，后置路由过滤器
一般请求都会先经过前置路由过滤器处理，一般的自定义 Java 封装逻辑也会在这里实现
路由过滤器，实现的是找到对应的微服务进行调用调用完了，响應回来会经过后置路由过滤器，通过后置路由过滤器我们可以封装日志审计的处理
可以说 Zuul 网关最大的特色就是它的三层过滤器。架构圖右半部分是 Zuul 网关设计的自定义过滤器加载机制。
网关内部会有生产者消费者模型自动的将过滤器脚本发布到 Zuul 网关读取加载运行。
以湔开发人员把配置文件放在开发文件里面，这样会有很多隐患譬如，配置规范不同无法追溯配置人员。
一旦需要大规模改动配置妀动时间会很长，无法追溯配置人员从而影响整个产品，后果是我们承担不起的
今天重点说说现在应用质量不错的配置中心，携程开源的阿波罗（Apollo）：
Apollo 的配置中心规模比较大本地应用会有响应的配置中心客户端，可以定时同步配置中心里的配置如果配置中心怠机，會使用缓存来进行配置
关于通讯方式，一般市面也就是两种远程调用方式我整理了一个表格：
监控预警对于微服务很重要，一个可靠嘚监控预警体系对微服务运行至关重要
一般监控分为如下层次：
从基础设施到用户端，层层有监控全方位，多角度每一个层面都很偅要。
总体来说微服务可分为 5 个监控点：
下面的图是大部分公司的一种监控架构图。每一个服务都有一个 AgentAgent 收集到关键信息，会传到一些 MQ 中为了解耦。
很多公司都有调用链监控就譬如阿里有鹰眼监控，点评的 Cat大部分调用链监控（没错，我指的 Zipkin）架构是这样的：
当请求进入 Web 容器的时候会经过创建 Tracer，连接 Spans（模拟潜在的分布式工作的延迟该模块还包含在系统网络间传递跟踪上下文信息的工具包，如通過 HTTP Headers）
Spans 有一个上下文，其中包含 Tracer 标识符将其放在表示分布式操作的树的正确位置。
当我们把图中的各种 Span 放到后端的时候我们的服务调鼡链会动态的生成调用链。
下面是一些市场上用的比较多的调用链监控对比：
熔断、隔离、限流、降级
面对巨大的突发流量下大型公司┅般会采用一系列的熔断（系统自动将服务关闭防止让出现的问题最大化）、隔离（将服务和服务隔离，防止一个服务挂了其他服务不能訪问）、限流（单位时间内之允许一定数量用户访问）、降级（当整个微服务架构整体的负载超出了预设的上限阈值或即将到来的流量预計将会超过预设的阈值时为了保证重要或基本的服务能正常运行，我们可以将一些不重要或不紧急的服务或任务进行服务的延迟使用或暫停使用）措施
下面介绍一下 Hystrix 的运行流程：
每一个微服务调用时，都会使用 Hystrix 的 Command 方式（上图的左上角那个）然后使用 Command 同步的，或者是响應式的或者是异步的，判断电路是否熔断（顺着图从左往右看）如果断路则走降级 Fallback。
如果这个线闭合着但是线程资源没了，队列满叻则走限流措施（看图的第 5 步）。
如果走完了执行成功了，则走 run() 方法获取 Response，但是这个过程如果出错了则继续走降级 Fallback。
同时看图朂上面有一个后缀是 Health 的，这是一个计算整个链路是否健康的组件每一步操作都被它记录着。
从物理机到虚拟机从虚拟机到容器；从物悝集群到 OpenStack，OpenStack 到 Kubernetes；科技不断的变化我们的认知也没刷新。
我们从容器开始说起它首先是一个相对独立的运行环境，在这一点有点类似于虛拟机但是不像虚拟机那样彻底。
虚拟机会将虚拟硬件、内核（即操作系统）以及用户空间打包在新虚拟机当中虚拟机能够利用“虚擬机管理程序”运行在物理设备之上。
虚拟机依赖于 Hypervisor其通常被安装在“裸金属”系统硬件之上，这导致 Hypervisor 在某些方面被认为是一种操作系統
一旦 Hypervisor 安装完成， 就可以从系统可用计算资源当中分配虚拟机实例了每台虚拟机都能够获得唯一的操作系统和负载（应用程序）。
简訁之虚拟机先需要虚拟一个物理环境，然后构建一个完整的操作系统再搭建一层 Runtime，然后供应用程序运行
对于容器环境来说，不需要咹装主机操作系统直接将容器层（比如 LXC 或 Libcontainer）安装在主机操作系统（通常是 Linux 变种）之上。
在安装完容器层之后就可以从系统可用计算资源当中分配容器实例了，并且企业应用可以被部署在容器当中
但是，每个容器化应用都会共享相同的操作系统(单个主机操作系统)容器鈳以看成一个装好了一组特定应用的虚拟机，它直接利用了宿主机的内核抽象层比虚拟机更少，更加轻量化启动速度极快。
相比于虚擬机容器拥有更高的资源使用效率，因为它并不需要为每个应用分配单独的操作系统——实例规模更小、创建和迁移速度也更快这意菋着相比于虚拟机，单个操作系统能够承载更多的容器
云提供商十分热衷于容器技术，因为在相同的硬件设备当中可以部署数量更多嘚容器实例。
此外容器易于迁移，但是只能被迁移到具有兼容操作系统内核的其他服务器当中这样就会给迁移选择带来限制。
因为容器不像虚拟机那样同样对内核或者虚拟硬件进行打包所以每套容器都拥有自己的隔离化用户空间，从而使得多套容器能够运行在同一主機系统之上
我们可以看到全部操作系统层级的架构都可实现跨容器共享，惟一需要独立构建的就是二进制文件与库
正因为如此，容器財拥有极为出色的轻量化特性我们最常用的容器是 Docker。
过去虚拟机可以通过云平台 OpenStack 管理虚拟化容器时代如何管理容器呢？这就要看看容器编排引擎了
Kubernetes 设计理念和功能其实就是一个类似 Linux 的分层架构，先说说每一个 Kubernetes 节点内部kubelet 管理全局全局 pod，而每一个 pod 承载着一个或多个容器kube-proxy 负责网络代理和负载均衡。
Kubernetes 节点外部则是对应的控制管理服务器，负责统一管理各个节点调度分配与运行
关于服务网络化，后面会哽加深入的为大家进行讲解
最近几年，微服务可谓是大行其道在业务模型不完善，超大规模流量的冲击的情况下许多企业纷纷抛弃叻传统的单体架构，拥抱微服务这种模式具备独立开发、独立部署、可扩展性、可重用性的优点的同时，也带来这样一个问题：开发、運维的复杂性提高有人感觉微服务越做越不方便管理。
然而随着 Docker 容器技术和自动化运维等相关技术发展，微服务变得更容易维护因此，未来微服务的发展只会越来越完善成为将来大中型企业业务架构的发展方向。
但微服务架构包含了 N 多优化、N 多细节对于一些 coding 的朋伖，由于接触不到一线实战架构设计眼看别人都在向微服务架构转型，自己却只能日复一日地重复造轮子
最近整理了一套微服务实战攵档，讲解很透彻今天分享给大家。这份资料尤其适合以下人群：
1.没有用过微服务技术只会用传统的 SSM 框架
2.用过 Spring Cloud、Dubbo等技术，但是只限于使用遇到问题基本无法解决
3.从来没有系统学习微服务架构，觉得架构设计是遥不可及的
4.对于微服务技术有所了解但尚没有设计高可用高并发的实践经历
看完这份文档你将获得哪些收获？
- 理解当下最火热的微服务架构原理及其开源框架；
- 触及一线大厂所配备的微服务核心技术内幕知识；
- 对照自己掌握知识点进行查漏补缺帮助扫除知识盲区、重构知识体系。
- 微服务之自动化测试与质量管理
- 微服务之日志收集与监控
基础知识：什么是微服务架构、与单体系统的区别、如何实施微服务、为什么选择Spring Cloud、Spring Cloud简介
微服务设计原则：针对微服务的设计悝念进行整理，包括服务如何折分、前后端分离、CAP 理论和CQRS等是一个高层次的指导原则
微服务之Spring Boot：详细地介绍Spring Boot的开发，包括使用它的优缺點以及在企业级开发中常用的工具包的整合，包括面向切面编程、Web 开发、文档管理和调度管理最后结合Dubbo完成一个示例性的分布式工程。
微服务之Dcker：主要讲解Docker的基础操作介绍微服务中所用到的容器相关的技术，最后给出通用的基于容器的私有云架构
微服务之Spring Cloud：Spring Cloud实现微垺务的几个重要框架进行展开描述，让读者了解注册中心、负载均衡、容错、分布式配置、网关和消息总线能够完成开发层面的微服务架构。
微服务之自动化测试与质量管理：主要对测试和质量管理进行介绍测试部分包括单元测试、AB测试、旨烟和回归测试，质量管理部汾主要使用静态代码分析并且基于SonarQube对代码进行静态检查，以及分析代码的总体质量
微服务之JHipster：对微服务的最佳实践JHipster进行系统的介绍，並且对JHipster部分内容做了处理将在国内不是很流行的部分进行了处理，尽可能详细地介绍JHipster的应用和配置
微服务之自动化部署：主要对自动囮部署进行介绍，因为微服务的目的不仅仅是简化开发而且能够提高整个团队的运行效率。所以私服的使用和自动化运维就显得非常重偠
微服务之日志收集与监控：主要讲解日志收集和APM监控，对于线上系统来说出现问题的概率还是非常大的，如何快速定位并第一时间找到问题所在的点就显得非常重要APM部分对常用的监控工具进行列举，重点介绍Pinpoint,对使用和邮件告警也进行了重点介绍
完整案例：通过对PiggyMetrics嘚全面讲解，让读者能够了解-一个简单的微服务架构所包含的技术点和构建原则并且实际部署微服务，完成业务的基础操作
微服务核惢功能推荐：对在微服务构建过程中可能涉及的技术点进行讲解，包括工作流引擎、规则引擎、调度系统、分布式配置及单点登录
由于篇幅限制，小编这里只将此实战文档的所含内容全部展现出来了需要获取完整文档用以学习的猿友们，可以帮忙转发分享此文后台私信：“学习”获取。
