微服务与服务治理

什么是微服务

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务和服务之间采用轻量级的通信机制相互沟通（通常是HTTP或RPC).每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建

为什么需要微服务

因为传统的单体应用，在功能越来越复杂后，存在一些天然缺陷：

• 代码臃肿，应用启动时间长
• 回归测试周期长，修复一个bug可能需要对所有关键业务进行回归测试。
• 应用容错性差，某个小功能的程序错误可能导致整个系统宕机；
• 伸缩困难，单体应用扩展性能时只能整个应用进行扩展，造成计算资源浪费。
• 开发协作困难，一个大型应用系统，可能几十个甚至上百个开发人员，大家都在维护一套代码的话，代码merge复杂度急剧增加。

微服务架构 vs 单体应用 优缺点

优点：

1. 提升开发交流，每个服务足够内聚，足够小，代码容易理解；
2. 服务独立测试、部署、升级、发布；
3. 按需定制，资源利用率高，每个服务可以各自进行扩展，而且每个服务可以根据自己的需要部署到合适的硬件服务器上；
4. 每个服务按需选择接受服务的实例个数；
5. 容易扩大开发团队，可以针对每个服务组建开发团队；
6. 提高容错性，一个服务的内存泄露并不会让整个系统瘫痪；
7. 新技术的应用，系统不会被长期限制在某个技术栈上；

缺点：

1. 微服务提高了系统的复杂度；
2. 开发人员要处理分布式系统的复杂性；
3. 服务之间的分布式通信问题；
4. 服务的注册与发现问题；
5. 服务之间的分布式事务问题；
6. 数据隔离再来的报表处理问题；
7. 服务之间的分布式一致性问题；
8. 服务管理的复杂性，服务的编排；
9. 不同服务实例的管理。

服务治理：为了解决微服务架构带来的问题

• 所谓“治理”，字面上包含了对被治理对象的问题梳理及改进优化的意思。服务治理是IT治理的一部分，它重点关注服务生命周期的相关要素，包括服务的架构、设计、发布、发现、版本治理、线上监控、线上管控、故障定界定位、安全性等。
• 在服务的架构体系中，由于服务的提供者和服务的使用者分别运行在不同的进程中，甚至在不同的物理节点上，并由不同的团队开发和维护。团队的协作和服务的协同，都需要进行大量的协调工作。协调工作越多，复杂度越高。任何事物，一旦有了复杂度，伴随着就有了治理的需求，通过治理，为协调工作立规范、打基础、并时时监控，不断优化协调的效率，以期降低复杂度，规避风险，这就是服务治理的由来。
• 服务的治理既要进行线上的治理，也要进行线下的治理，通过线上线下两大维度进行治理指标的采集，并把它们统一汇总到指标中心，进行综合的汇总、聚合、分析，获得对服务的客观度。
• 这些度量指标中，有相当一部分线上的性能及异常指标会被转化为运维事件，一旦触发我们预先设置的阈值，就会更进一步转化成“管控指令”，并通过调度中心下发，进行服务的弹性伸缩、扩容缩容等资源调度操作，或者进行服务的限流、降级、容错、路由调整等管控操作。
• 另外一部分度量指标，包括架构、开发、测试、运维、过程协作效率等指标会通过治理委员会（泛指，治理成员的集合）进行人为的深入分析，并制定出治理决策，这些治理决策会通过相关的过程优化管理措施进行落地。这样，通过服务的度量、管控、管理这三大举措，就可以构建起一个三位一体、围绕服务治理的闭环体系。

微服务有哪些问题需要治理

1. 服务注册与发现。单体服务拆分为微服务后，如果微服务之间存在调用依赖，就需要得到目标服务的服务地址，也就是微服务治理的”服务发现“。要完成服务发现，就需要将服务信息存储到某个载体，载体本身即是微服务治理的”服务注册中心“，而存储到载体的动作即是”服务注册“。
2. 可观测性。包括 监控、日志、调用追踪，调用拓扑关系等。微服务由于较单体应用有了更多的部署载体，需要对众多服务间的调用关系、状态有清晰的掌控。
3. 流量管理。由于微服务本身存在不同版本，在版本更迭过程中，需要对微服务间调用进行控制，以完成微服务版本更迭的平滑。这一过程中需要根据流量的特征（访问参数等）、百分比向不同版本服务分发，这也孵化出灰度发布、蓝绿发布、A/B测试等服务治理的细分主题。
4. 安全。不同微服务承载自身独有的业务职责，对于业务敏感的微服务，需要网关对其他服务的访问进行认证与鉴权，也就是安全问题。
5. 高可用。使用熔断限流降级等方式，来应对服务不可用带来的各种风险。
6. 控制。对服务治理能力充分建设后，就需要有足够的控制能力，能实时进行服务治理策略向微服务分发。