需要哪些治理环节

Lewis共同提出(原文链接https://martinfowler.com/articles/microservices.html)他们定义了微服务是由单一应用程序构成的小服务拥有自己的进程与轻量化处理服务依业务功能设计以全自动的方式部署与其他服务使用HTTP

一组小的服务(涉及到服务拆分的粒度问题后面会涉及)独立进程轻量级通信(Rest和RPC)独立部署

清晰的模块边界各自独立部署互不影响各个服务可选择不同的技术实现

分布式复杂性(从单体到微服务系统内部复杂度降低同时外部复杂度增加)数据一致性问题运维复杂度更高测试复杂度更高

引入时机

前期业务不复杂的情况下不建议引入微服务。

对于一个业务一开始就应该是怎么快怎么来快速迭代快速验证产品。

随着业务不断发展越来越复杂整个生产力开始下降的时候就可以开始考虑引入微服务了。

在引入微服务的时候整体的一个思路是选择一个非核心模块开始微服务化将微服务整套核心基础设施落地(核心基础设施后面会涉及)然后渐进式地去微服务化其他模块稳步前进。

需要哪些治理环节

可观测性(日志Logs、监控Metrics、链路追踪Trace)

单体架构

早期开发的时候一个war包或者jar包里面包含了一个应用的所有功能这样的架构我们叫作单体架构。

单体架构足够简单可以快速开发和上线适用于项目初期业务简单、用户量不大的情况。

集群和垂直化

垂直化按照业务的垂直领域进行划分降低业务的耦合度同时提高应用的可伸缩性。

SOA

面向服务架构核心目标是把一些通用的、会被多个上层服务调用的共享业务提取成独立的基础服务这些被提取出来的共享服务相对来说比较独立并且可以重用。

所以在SOA中服务是最核心的抽象手段业务被划分为一些粗粒度的业务服务和业务流程。

微服务架构

由于SOA和微服务它们的关注点不同就导致了它们之间有非常大的区别

SOA关注的是服务的重用性和信息孤岛问题微服务关注的是业务解耦。

微服务架构使得服务粒度细化之后开发运维也变得更加重要和容器技术也结合得更加紧密。

如何实现微服务架构

更多的时候大家可能都是按照业务流程来进行服务的拆分的。

除此之外我们还可以按照性能、业务重要程度、可用性、稳定性这些维度来进行微服务的拆分具体采取什么方式可以视具体情况而定。

那关于服务的粒度我们应该如何把握呢粒度太细或太粗都不太合适粒度太细会导致开发、测试、运维更加复杂整体性能会降低等粒度太粗又会导致达不到我们的预期服务之间依赖太大。

这里有一个技巧三个火**原则。

拆分微服务的数量服务端开发人数/3。

为什么不是2个人异常情况下一个人压力会比较大另外两个人维护的服务复杂度可能偏低。

为什么不是4个或者更多开发人员多了之后每个人不一定能掌握单个服务的所有细节。

主流微服务解决方案

服务接入层服务网关服务流控服务降级服务安全。

服务运行层服务注册服务发现服务路由服务容错。

技术支撑层接口框架分布式事务自动化测试容器编排自动化部署灰度发布服务监控服务跟踪。

基础设施层配置中心日志中心分布式锁消息队列。

服务接入层

技术支撑层。

其中微服务框架的核心是服务注册、服务发现和服务路由。

下一代微服务架构Service

Mesh是一种新型的用于处理服务与服务之间通信的技术尤其适用以云原生应用形式部署的服务能够保证服务与服务之间调用的可靠性。

在实际部署时Service

Mesh

通常以轻量级的网络代理的方式跟应用的代码部署在一起从而以应用无感知的方式实现服务治理。

Service

以轻量级的网络代理的方式与应用的代码部署在一起用于保证服务与服务之间调用的可靠性这与传统的微服务架构有着本质的区别这么做主要是出于两个原因

Service