2019年1月份，第一次听到“微服务”这个词，作为一名程序员，天生拥有好奇心，特意上网查了一下微服务的概念。整个2019年，利用工作后忙里偷闲的时间，学习了一下微服务相关技术，动手搭建了微服务架构程序，对微服务有了一定了解。
什么是微服务
前几年大部分程序员编写的是单体架构的程序。单体架构应用程序，可以理解为程序代码（包含前后端代码）、数据库都是在一台服务器上。通俗来讲微服务就是由一个个单体程序组成，每个单体程序由于业务关系，需要互相调用。
百科上微服务的简介是这样的。
微服务是一个新兴的软件架构，就是把一个大型的单个应用程序和服务拆分为数十个的支持微服务。一个微服务的策略可以让工作变得更为简便，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。
对于大型应用程序来说，增加更多的用户则意味着提供更大型的弹性计算云（EC2）实例规模，即便只是其中的一些功能扩大了规模亦是如此。其最终结果就是企业用户只需为支持超过微服务的那部分需求的EC2实例支付费用。
微服务架构
微服务主要由服务网关、配置中心、服务注册发现、服务熔断和降级、容错限流、链路追踪、服务监控、日志监控组成。
服务注册发现
在进行服务拆分之后，服务的数量会变得非常多，而每个服务又可能会有非常多的集群节点来提供服务，那么为保障系统的正常运行，必然需要有一个中心化的组件完成对各个服务的整合，即将分散于各处的服务进行汇总，汇总的信息可以是提供服务的组件名称、地址、数量等，每个组件拥有一个监听设备，当本组件内的某个服务的状态变化时报告至中心化的组件进行状态的更新。服务的调用方在请求某项服务时首先到中心化组件获取可提供该项服务的组件信息（IP、端口等），通过默认或自定义的策略选择该服务的某一提供者进行访问，实现服务的调用。那么这个中心化的组件我们一般称之为 服务中心，即服务注册发现。
配置中心
随着业务的发展，微服务架构的升级，服务的数量、应用的配置日益增多（各种微服务、各种服务器地址、各种参数），传统的配置文件方式和数据库的方式已经可能无法满足开发人员对配置管理的要求，同时对于配置的管理可能还会牵涉到 ACL 权限管理、配置版本管理和回滚、格式验证、配置灰度发布、集群配置隔离等问题，以及：
安全性：配置跟随源代码保存在版本管理系统中，容易造成配置泄漏
时效性：修改配置，需要每台服务器每个应用修改并重启服务
局限性：无法支持动态调整，例如日志开关、功能开关等
因此，我们可以通过一个配置中心以一种科学的管理方式来统一管理相关的配置。
服务熔断和降级
分布式系统中经常会出现由于某个基础服务不可用造成整个系统不可用的情况，这种现象被称为服务雪崩效应。为了应对服务雪崩，一种常见的做法是服务降级。
链路追踪
在微服务场景下，我们会拆分出来很多的服务，也就意味着一个业务请求，少则跨越 3-4 个服务，多则几十个甚至更多，在这种架构下我们需要对某一个问题进行 Debug 的时候是极其困难的一件事情，那么我们就需要一个调用链追踪系统来帮助我们动态地展示服务调用的链路，以便我们可以快速地对问题点进行定位，亦可根据链路信息对服务进行调优。
服务监控
微服务治理的一个核心需求便是服务可观察性。作为微服务的牧羊人，要做到时刻掌握各项服务的健康状态，并非易事。云原生时代这一领域内涌现出了诸多解决方案。本组件对可观察性当中的重要支柱遥测与监控进行了抽象，方便使用者与既有基础设施快速结合，同时避免供应商锁定。
