开发者学堂课程【Elasticsearch 实战进阶营：实操讲解：微服务运行状态监测（一）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/899/detail/14321
实操讲解：微服务运行状态监测（一）
内容简介
1介绍微服务体系以及技术
2介绍 Elastic Stack 技术栈
3微服务运行状态实时监测
大型微服务体系介绍以及 Spring Cloud 技术体系
1.大型微服体系概要组份
微服务是一种服务间松耦合的、每个服务之间高度自治并且使用轻量级协议进行通信的可持续集成部署的分布式架构体系。
包含了微服务的特点，微服务架构和其他架构的区别，以下对比一些常见的架构。
一个标准的一个，大厅微服务体系所涵盖的一些，基本的组件组成部分，首先从客户端客户端，包括有 H5Y BO A PP，然后再从进入到这个网关系统，再进入到的服务，那微这个服务里，就包含很多，有第一个有这种聚合服务叫 ig，还有一些这种所谓的原子性微服务，从网关开始，的移动端它可以直接去掉，用到恢复，也可以调聚合服务，聚合服务的什么意思就是把这个组合下面的一些微服务，然后在也可以微博会调用外部的一些服务’
通过这个图，可以看到的微服务，还有自己要会访问自己的中间件，比如说蕾丝，还有 kafka，然后数据库数据源，那数据库及更多，像 Sed 本身也是个数据库，然后像这个 Mexico，在整个这个微幅这个架构体系里面，它的优点，它把这些服务拆分成很细腻的力度，然后这样自由组合，在系统发布，各种分布式控制方面要优秀很多，比原有的单体结构要简单，要便捷，要灵活很多，这是现在最流行的这种架构体系，当然本质上说它就是一个 SOA 架构，如果深度的玩过去，So，其实对这个微幅一看便懂。
单体架构是最简单的软件架构，常用于传统的应用软件开发以及传统 Web 应用。传统 Web 应用，一般是将所有功能模块都打包（jar、war）在一个 Web 容器（JBoss、Tomcat）中部署、运行。随着业务复杂度增加、技术团队规模扩大，在一个单体应用中维护代码，会降低开发效率，即使是处理一个小需求，也需要将所有机器上的应用全部部署一遍，增加了运维的复杂度。
当某一天使用单体架构发现很难推进需求的开发、以及日积月累的技术债时，很多企业会开始做单体服务的拆分，拆分的方式一般有水平拆分和垂直拆分。
垂直拆分是把一个应用拆成松耦合的多个独立的应用，让应用可以独立部署。
有独立的团队进行维护；水平拆分是把一些通用的，会被很多上层服务调用的模块独立拆分出去，形成一个共享的基础服务，这样拆分可以对一些性能瓶颈的应用进行单独的优化和运维管理，也在一定程度上防止了垂直拆分的重复造轮子。
SOA 也叫面向服务的架构，从单体服务到 SOA 的演进，需要结合水平拆分及垂直拆分。
SOA 强调用统一的协议进行服务间的通信，服务间运行在彼此独立的硬件平台但是需通过统一的协议接口相互协作，也即将应用系统 服务化。举个易懂的例子，单体服务如果相当于一个快餐店，所有的服务员职责都是一样的，又要负责收银结算，又要负责做汉堡，又要负责端盘子，又要负责打扫，服务员之间不需要有交流，用户来了后，服务员从前到后负责到底。SOA 相当于让服务员有职责分工，收银员负责收银，厨师负责做汉堡，保洁阿姨负责打扫等，所有服务员需要用同一种语言交流，方便工作协调。
2.spring cloud 技术栈
通俗点说就是在搭建微服务架构师会出现各种问题，而 springCould 就是为开发人员构建微服务架构时，提供这些这些问题的一套解决方案，SpringCloud 是若干个框架的集合，它包括 spring-cloud-config、spring-cloud-bus 等近20个子项目，它提供了服务治理、服务网关、智能路由、负载均衡、断路器、监控跟踪、分布式消息队列、配置管理等领域的解决方案。
服务体系里面，这套圣诞其实是为了实现前面那一套这个微服务架构体系，满足的满足那一套微服务架构体系的这个基础的软件支持，那首先前面对称的对称，左边灰色的这个图，相当于是什么这个叫客户端，有 LG 设备，有移动端，有浏览器，那经过的网关网关 API gateway 地位，这个是 Spring cloud 里面自带的一个现在已申请，老师最早之前是用 rod，比较早，那网关进来之后，它会进入到的微服务。
那微服务体系就是刚前面也介绍那个图里面有 聚合服务，Ig 这种服务，然后有单独的微服务，然后服务之间，还有可能去调用外部的其他服务，那这个服务，可能数量非常的多，那这些服务呢，调动的时候他要做一个什么？
首先还要做一个服务的注册，所有微服务注册的时候注册到这个 register，在这个微斯人告诉你们叫 youka 的，现在也有换的，换到阿里的这个，还是以优雅为主了解，就是了解这个私人高的它自带的一些东西，后面就是以常规的，
比如付调用数据库调用的消息队列中间件，当然在微博里面它自带了很多所谓的这个，分布式追踪，这个强调-这个并不是思考的擅长的，阿斯玛咖本身只是个框架提供商，他并不擅长在数据领域，那监控其实讲的是数据，
维护监控主要监控，要监控一个。为什么去启动，需要到他的船舶动态社会的传播，这个维护自己有这个。有卡注册中心这边，但是他们紧紧的目的是为了服务的一个连贯性，不跟这个监控。本身观念不是特别大。举个例子，部署出一个什么商品服务。
要部署20个，其中如果挂了十个之后，那也能够控制到。那这个时候要告知，现在服务的数量以及 不足以，正常支撑。所以这时候你要做一个告警通知这个，就需要利用单独的产品去做，我不可能原有的这个。十分高的其实没有，它本身不擅长，就是因为这个涉及到数据的统计。就会接触到第三方，是奖励了一个进展怎样，会不会奖励制度。第二个，就是讲这个是我微博运营期间产生了大量的日志，有错误日志有信心，甚至还有 bug 各种。
键是真的分布在。所有的微博和各个机器上，各个节点上有可能是存在多块里面，但是这些日子。他有时候纯粹的心很重要，比如某一个交易订单失败，然后客户的钱汇款到哪个阶段有的时候，如果因为系统在更新，又做了一场有一些出现了异常，那这时候需要介入日志来分析，甚至回滚这样一个策略，就这样就需要一个中心化的这个平台把他们全部采集起来。
