微服务的概念最早是在2012年提出的，在MartinFowler的大力推动下，微服务在2014年后得到了蓬勃发展。今天我们梳理一下微服务的核心架构通过一组手绘图实现微服务。图片来自Pexels什么是微服务？微服务之父MartinFowler对微服务的总体概述如下：目前，微服务行业还没有统一标准的定义（同时也没有对这种架构风格的精确定义）。但总的来说，微服务架构是一种架构模式或架构风格，提倡将单个应用程序划分为一组小的服务，每个小服务运行在自己独立的进程中，服务之间相互协调配合，为用户提供服务与最终价值。服务使用轻量级通信机制（通常是基于HTTP的RESTfulAPI）相互通信。每个服务都围绕特定的业务构建，可以独立部署到生产环境、类生产环境等。另外，要尽量避免统一集中的服务管理机制。对于具体的服务，根据业务上下文选择合适的语言和工具来构建，可以做到非常轻量级的集中管理。协调这些服务。服务可以用不同的语言编写，可以使用不同的数据存储。根据MartinFowler的描述，我总结了以下几点：①小服务小服务没有具体的标准或规范，但从整体规范上来说一定是小的。②进程独立性每组服务独立运行。也许我的服务运行在Tomcat容器中，而另一个服务运行在Jetty上。整个服务可以通过流程不断横向扩展。③通信协议以前是很重的，像ESB，像SOAP，轻通信，就是说相对于过去，更智能更轻的服务相互调用，所谓smartendpoints和dumbpipes。这些Endpoints都是解耦的，连接这些MicroServices完成一次业务通信调用，就像Linux系统中通过管道连接一系列命令服务一样。在以往的业务中，我们通常会考虑系统耦合带来的各种依赖和问题。微服务让开发者更专注于业务逻辑开发。④部署不仅要业务独立，还要独立部署。但是，这也意味着传统的开发流程会发生一定程度的改变，开发也要承担一定的运维责任。⑤管理传统的企业级SOA服务往往规模庞大、难以管理、耦合度高、开发团队成本高。微服务允许团队选择自己的技术来实施。不同的服务可以根据自己的需求选择不同的技术栈来实现自己的业务逻辑。微服务的优缺点为什么要使用微服务？因为很好玩？没有。以下是我在网上找到的比较全面的优点：优点是每个服务足够内聚，足够小，代码容易理解，可以专注于指定的业务功能或业务需求。开发简单，提高开发效率。一项服务可能只专注于一件事。微服务可以由2到5名开发人员组成的小团队单独开发。微服务是松散耦合且功能有意义的服务，无论是在开发阶段还是部署阶段都是独立的。可以使用不同的语言开发微服务。易于与第三方集成，微服务允许通过Jenkins、Hudson、bamboo等持续集成工具轻松灵活地集成自动化部署。微服务易于单个开发人员理解、修改和维护，让小团队可以更专注于自己的工作。价值不需要合作。微服务允许您利用最新技术。微服务只是业务逻辑代码，没有与HTML、CSS或其他界面组件混合。每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一的数据库。总的来说，微服务的优势在于，面对大型系统，可以有效降低复杂度，让服务架构的逻辑更加清晰。但是这也会带来很多问题，比如分布式环境下的数据一致性，测试的复杂性，运维的复杂性。哪些组织适合使用微服务？微服务带来各种优势和劣势，那么哪些组织适合使用微服务呢？①墨菲定律（设计系统）和康威定律（系统划分）多年前就提出了微服务的概念。在康威的这篇文章中，最著名的一句话是：Organizationswhichdesignsystemsareconstrainedtoproducedesignswhicharecopysofthecommunicationstructuresoftheseorganizations.-MelvinConway(1967)中文直译大概意思是：设计系统的组织，由此产生的设计相当于组织内部和组织之间的沟通结构。看看下图，再想想苹果的产品和微软的产品设计，就能形象地理解这句话。有兴趣的可以研究一下！②架构演进架构在不断演进，微服务也是如此。当各大科技公司的规模达到一定程度后，需要演化为技术架构体系，进行进一步的管理。传统的团队都是面向过程的。想好了产品，就去找策划人员，策划好之后，就去找开发人员，然后一步步按部就班。我们为产品做技术。一旦过程中出现问题，回过头来查找问题将非常耗时。使用微服务架构体系，团队组织需要转变为跨职能的团队，即每个团队都有产品专家、策划专家、开发专家、运维专家。他们使用API??发布他们的功能，平台使用他们的Feature发布产品。微服务技术架构体系分享一下大部分公司使用的微服务技术架构体系：服务发现主流的服务发现分为三种：第一，开发者开发完程序后，找运维伙伴一个域名，如果服务被使用，我们可以通过DNS找到我们对应的服务。缺点是负载均衡服务可能存在相当大的性能问题，因为该服务没有负载均衡功能。二是目前普遍的做法。可以参考Zuul网关。每个服务通过服务器内置的功能注册到注册中心。服务消费者不断轮询注册中心寻找对应的服务，并使用内置的负载均衡来调用服务。缺点是不太适合多语言环境，需要单独为消费者客户端开发服务发现和负载均衡功能。当然这种方式通常用在SpringCloud上。三是将客户端和负载均衡器放在同一台主机上，而不是在同一个进程中。与第一种和第二种方法相比，这种方法改善了它们的缺点，但会大大增加运维成本。网关微服务的网关是什么？我们其实可以结合生活来想一想。每个大公司都有自己的建筑区，而这个建筑区内的守卫也不少。如果有外人进入公司，他会先和门卫打招呼再进去。把实际生活和微服务联系起来就不难理解网关的含义：网关的作用如下：反向路由：很多时候，公司不希望外人看到我们公司的内部，所以他们需要网关进行反向路由。也就是将外部请求转化为内部特定的服务调用。安全认证：网络中会有很多恶意访问，比如爬虫，比如黑客攻击，网关保持安全功能。限流熔断器：当很多服务被请求不堪重负时，我们的服务会自动关闭，导致服务无法使用。限流保险丝可以有效避免此类问题。日志监控：所有外部请求都会经过网关，所以我们可以使用网关来记录日志信息。灰度发布，蓝绿部署。指的是一种可以平滑过渡的发布方式。可以对其进行A/B测试。即让部分用户继续使用产品特性A，部分用户开始使用产品特性B。如果用户对B没有异议，则逐步扩大范围，将所有用户迁移到B。开源网关Zuul架构：Zuul网关的核心其实是一个Servlet。所有的请求都会通过ZuulServlet传递给ZuulFilterRunner，然后分发给三个过滤器。先说架构图的左半部分，分别是Groovy实现的路由前过滤器、路由过滤器和路由后过滤器。一般请求都会先经过路由前的过滤器处理，一般的自定义Java封装逻辑也会在这里实现。路由过滤器的实现是为了找到对应的微服务来调用。调用完成后，响应将通过路由后过滤器。通过路由后过滤器，我们可以封装日志审计的处理。可以说Zuul网关最大的特点就是它的三层过滤器。架构图右半部分是Zuul网关设计的自定义过滤器加载机制。网关内部会有生产者-消费者模型，自动将过滤脚本发布到Zuul网关进行读取、加载和运行。在没有配置中心之前，开发人员将配置文件放在开发文件中，这样会有很多隐患。例如，配置规范不同，无法追踪配置人员。一旦需要大规模更改配置，修改时间会很长，而且无法追踪配置人员，影响整个产品，后果我们承担不起。于是就有了配置中心！目前的开源中心有百度配置中心Disconf、SpringCloudConfig、Apollo。今天重点介绍一下应用质量不错的配置中心，携程开源的Apollo：Apollo的配置中心比较大，本地应用会有响应式的配置中心客户端，可以定时同步配置中心里的配置。如果配置中心空闲，则使用缓存进行配置。通讯方式关于通讯方式，市场上一般有两种远程调用方式。我整理了一张表：监控预警监控预警对于微服务来说非常重要，一个可靠的监控预警系统对于微服务的运行至关重要。一般监控分为以下几个层次：从基础设施到用户端，都有监控层，全方位，多角度，每个层次都很重要。总的来说，微服务可以分为五个监控点：日志监控Metrics监控健康检查调用链检查报警系统①监控架构下图是大部分公司的监控架构图。每个服务都有一个Agent，Agent收集关键信息发送给一些MQ进行解耦。同时将日志传递给ELK，将Metrics传递给InfluxDB时序库。并且和Nagios一样，可以周期性的向Agent发起信息查询微服务。②调用链监控很多APM公司都有调用链监控。比如阿里有Hawkeye监控，评论Cat，大部分的调用链监控（是的，我说的是Zipkin）架构是这样的：当一个请求进入Web容器的时候，Tracer会被创建，连接到Spans（到模拟潜在分布式工作的延迟，该模块还包含一个工具包，用于在系统网络之间传递跟踪上下文信息，例如通过HTTP标头）。跨度有一个包含Tracer标识符的上下文，将其放在表示分布式操作的树中的正确位置。当我们将图中的各个Span放入后端后，我们的服务调用链就会动态生成一条调用链。下面是市场上使用比较多的一些调用链监控的对比：熔断、隔离、限流、降级面对巨大的突发流量，大公司一般采用一系列的熔断（系统自动关闭服务）防止出现最大化问题），隔离（将服务与服务隔离，防止一个服务挂掉，其他服务无法访问），限流（单位时间内允许一定数量的用户访问），降级（当当整个微服务架构的整体负载超过预设的上限阈值或者即将到来的流量预计会超过预设的阈值时，为了保证重要或者基础服务的正常运行，我们可以延迟使用一些不重要或者非紧急服务或任务或暂停使用）措施。下面介绍一下Hystrix的运行过程：每个微服务在被调用的时候，都会使用Hystrix的Command方法（上图左上角的那个），然后通过Command进行同步，或者响应，或者异步，判断是否电路是Fuse（下图从左到右），如果电路坏了，会采取降级Fallback。如果线路关闭了，但是线程资源没了，队列满了，就采取限流措施（见图中的第5步）。如果执行完，执行成功，再去run()方法获取Response，但是如果这个过程出错，继续降级Fallback。同时在图片的最上方有一个Health的后缀，是一个计算整个链路是否健康的组件，每一次操作都被它记录下来。容器和服务编排引擎从物理机到虚拟机，从虚拟机到容器；从物理集群到OpenStack，从OpenStack到Kubernetes；技术在不断变化，我们的认知一直没有被刷新。让我们从一个容器开始。是一个相对独立的运行环境。在这一点上，它有点类似于虚拟机，但是没有虚拟机那么彻底。虚拟机将虚拟硬件、内核（即操作系统）和用户空间打包成一个新的虚拟机，虚拟机可以使用“hypervisor”在物理设备上运行。虚拟机依赖于管理程序，它通常安装在“裸机”系统硬件之上，这导致管理程序在某些方面被视为操作系统。一旦安装了管理程序，就可以从系统可用的计算资源中分配虚拟机实例，每个虚拟机可以获得唯一的操作系统和工作负载（应用程序）。简而言之，虚拟机首先要虚拟出一个物理环境，然后构建一个完整的操作系统，再构建一层Runtime，然后才能让应用运行起来。对于容器环境，不需要安装主机操作系统，容器层（如LXC或Libcontainer）直接安装在主机操作系统（通常是Linux变体）之上。容器层安装完成后，可以从系统可用的计算资源中分配容器实例，将企业应用部署到容器中。但是，每个容器化应用程序将共享相同的操作系统（单主机操作系统）。容器可以看作是安装了一组特定应用程序的虚拟机。它直接使用主机的内核。它比虚拟机抽象层更少，更轻量级，启动速度极快。容器比虚拟机更能节省资源，因为它们不需要为每个应用程序使用单独的操作系统——实例更小，创建和迁移速度更快。这意味着单个操作系统可以承载比虚拟机更多的容器。云提供商非常热衷于容器技术，因为可以在同一硬件设备上部署更多的容器实例。此外，容器易于迁移，但只能迁移到具有兼容操作系统内核的其他服务器，从而限制了迁移选项。因为容器不像虚拟机那样封装内核或虚拟硬件，所以每套容器都有自己隔离的用户空间，允许多套容器运行在同一个主机系统上。我们可以看到，所有操作系统级的架构都可以跨容器共享，需要独立构建的只有二进制文件和库。正因为如此，容器具有优良的轻量化特性。我们最常使用的容器是Docker。①容器编排过去可以通过云平台OpenStack来管理虚拟机。容器时代如何管理容器？这取决于容器编排引擎。ApacheMesos：Mesos基于主从架构。框架决定了如何使用资源。Master负责管理机器。Slave会周期性的向Master汇报机器状态，Master再将信息发送给framework。Master是高可用的，因为ZK也有Leader。下面是架构图：Kubernetes：Kubernetes是最近非常流行的开源容器编排引擎。详细可以参考前几天分享的一篇文章《我花了10个小时，写出了这篇K8S架构解析》：Kubernetes的设计理念和功能其实是类似Linux的分层架构。在每个Kubernetes节点中，kubelet管理全局全局pod，每个pod承载一个或多个容器，kube-proxy负责网络代理和负载均衡。Kubernetes节点外是相应的控制管理服务器，负责统一管理各个节点的调度、分配和运行。②服务网格化关于服务网络化，后面会做更深入的讲解。资料文档：MartinFowler对微服务的描述微服务架构的理论基础——康威定律Zipkin、Pinpoint、SkyWalking、调用链选择的CAT
