微服务架构介绍
1、微服务架构诞生背景
在互联网晚期即 Web 1.0 的时代，过后风行的是单体利用，研发团队比拟小，次要是内部网页，而后新闻门户等；到了新世纪的互联网期间即 Web 2.0 时代，网民数量大幅激增，电商社交这样巨无霸级别的互联网产品相继呈现，因而流量及业务复杂度相较于上一个时代有了质的变动。此时呈现了几百人甚至上千的研发团队在一个场景下，因而单体服务的弊病：例如研发效率等问题，就显现出来了。
这时呈现了一个叫 SOA 的架构，其架构思路与微服务很像，它还有相似于 ESB 这种中心化组件，阿里的 HSF，包含起初开源的 Double，都是在这个阶段诞生的。
挪动互联网时代呈现之后，各种各样的 APP 呈现，生存也开始全面的互联网化。大流量高并发以及规模化的研发团队变得越来越广泛，相应地对于高技术生产力的要求也在逐渐晋升，微服务的概念就应运而生。
微服务其实始终贯通在整个架构的倒退过程中。在 Java 的技术栈，相似于 Spring Cloud、Double 这些框架都曾经十分风行。不难发现整个社会曾经步入数字化高速倒退阶段，此时更大的问题蕴含其中，比方流量升高、整个利用的复杂度晋升，研发团队扩充、对于效率的要求增高等。
2、单体期间 1.0 版本
大部分的公司或者晚期的业务都会经验过这样一个过程，最后是客户端，此时拜访的话须要通过一个入口，上图中的 SLB 是阿里云一个负载平衡服务，它相当于一个网络入口，能够对应到 ECS（ECS 就是阿里云的虚拟机）打到对应的单体的服务中，此时他们会共用一个数据库，这是第一个期间。
3、单体期间 2.0 版本
到第二个期间 SOA 架构，它带来了分治的思维，它会将一些业务去进行拆分。但此时它还并未做到服务与底层的拆分，如存储数据库的一个拆分，实质上还是共用一套数据库，所以它还是单体的架构。
4、微服务期间
到了微服务期间，如果客户端通过 SLB 拜访了一个网关（如图所示），随后会转发到对应的服务，服务与服务之间会产生一些调用。每个服务会对应一个独自的数据库或者是缓存，并且每个服务通过相似于 Nacos 这种服务进行注册发现以及配置管理。微服务引入之后，尽管解决了架构业务的拆散，让研发团队在某一个畛域、业务可能做到精专。不过从整体架构来看就会发现，相较于之前它其实是更为简单，所以也带来一些运维上的问题。
在单体架构中，对于单体利用来说，会产生边界不清晰，模块耦合、共享代码库容易抵触等问题，同时如果团队规模很大，此时合作效率也会绝对较低。然而微服务架构中的外围就是解耦，如果做到拆分之后的解耦，就能够开释开发团队效率。
云原生时代微服务架构倒退
1、微服务技术在云原生时代的技术引进
云原生是一个很宏观的概念，如果咱们以微服务为终点来看云原生给微服务带来的变动与演进，能够帮忙咱们更好的了解什么是云原生。
微服务和单体利用的实质是什么呢？如图所示，它其实是把单体利用从一个巨型的利用拆分成数个渺小的服务，而后合作来实现原先单体利用等效的业务服务。此时微服务与微服务之间会造成一个依赖关系，因而它可能会须要部署到一个或者多个资源上，这时的资源就是计算资源。
已经的单体利用与资源之间的关系非常简略，单体利用的协同也都是一些外部协同，不存在内部动静的依赖。架构转换到微服务之后，因为内部依赖和节点数量的爆炸，整个体系会变成网状，治理起来十分复杂。超过 50% 的企业会感觉采纳微服务架构，最大挑战是简单的运维，即整个服务生命周期的治理。
现在，比拟公认的一点是云原生的根基，在于容器与容器的治理编排（K8S）。而容器与 K8S 的技术能帮忙咱们解决微服务体系存在的繁冗运维问题。
首先不同的微服务之间会存在异构，就是一个团队，他在微服务体系下为了施展最大效力，可能会容许不同的小团队采纳不同的编程语言，甚至不同的运行环境来运行这些微服务。因而咱们在运维和治理这些微服务时，最后都是没有对立的规范去解决这些异构环境的。这也就是为什么起初云原生的容器技术变得十分风行，因为其作用就是通过一层标准化的封装以及规范的运行时来限度微服务部署。这样从生命周期与治理角度来说，每一个微服务之间的差别变少，比拟利于资源的调度。
随后基于容器调度，就衍生出了容器平台。容器平台是什么呢？它其实就是治理容器的。就 K8S 来说它可能十分标准化的将微服务最便捷的运行到底层的资源上。随后存储计算网络，它能够通过 K8S 这一层来进行对立的封装，一层形象与封装，它就相似于云原生时代的操作系统。
它具体是提供哪些帮忙呢？在 K8S 外面有个概念叫 POD，POD 其实是一组容器的联合，与微服务实体生命周期的耦合。在一个 POD 外面，它能够运行一个或者是多个容器。
采纳微服务架构时，个别都会把微服务运行的主体放在主容器里，也就是把微服务执行的主逻辑放在主容器外面，此时主容器的生命周期与 POD 的生命周期是齐全耦合的。即 POD 什么时候沦亡，微服的运行主体便何时沦亡。除此之外咱们还会运行一些边车容器，亦称 Sidecar，它次要是为主容器提供一些辅助的性能，如日志采集、网络代理身份鉴权等，都能够放在 Sidecar 里。这样微服务就具备了一种超能力，除了提供本身外围业务以外，它还能够动静的提供额定辅助能力，让微服务的治理变得更加强壮与便捷。
此外 POD 这个模型还提供了许多十分有用的性能。比方状态信息，状态信息是指：POD 会提供一个规范的接口来显示运行时的状态。通过这个信息状态能够判断微服务或容器的整个运行状态。例如它是否正在运行中、业务是否曾经筹备好能够迎接流量的接入，它为整体的稳定性提供了保障。另一个是地址服务，地址服务就是每个 POD 会有一个标准化的 DNS 的地址服务，它对于须要对立裸露进去的 API，像日志监控追踪能力都有十分大的帮忙。通过 DNS 的日志地址来拜访，或者裸露的可观测性的一些信息，能够及时发现运行时的问题。因而咱们能够看到容器以及容器平台，可能在宏观上帮微服务具备更多的能力。
图中为 4 种公布模型：
1、滚动更新，
2、固定更新。
3、蓝绿部署
4、金丝雀公布（灰度公布）
流量治理
微服务将已经单体时代的动态通信关系，通过拆分编成动静运行时。服务间的通信与协同通常须要独自治理，微服务框架帮忙咱们进行了每个服务通用性能的形象与实现。
在形象层面，蕴含两方面：业务逻辑与通信、流量以及服务治理能力。咱们能够将底层一个通用能力形象成一个具体的框架，然而不同微服务之间的框架，没方法实现相互间的调用。然而云原生时代它便能够应用不同的开发语言以及模型进行编程，实现微服务的研发。
Service Mesh 服务网格就是为了解决流量治理在多语言，多环境下的问题而呈现的。
在数据层面，Sidecar 负责流量劫持转发以及治理，该性能典型 Sidecar 实现就是 Envoy。
如图它会先将下面那些从框架层面形象进去，随后与业务间接进行解耦，并将通用能力放在 Sidecar 中，通过 Sidecar 之间的通信、转发去治理；这样便会使问题变得简略很多。而咱们也只须要让流量治理和 Sidecar 之间进行通信，此时不同技术栈的微服务实例就可能相互进行通信了。
在管控层面，也须要一个组件来实现原微服务体系中的策略规定的治理，经典实现就是 Istio。
整体来说，除了数据层面，咱们还须要管控层面的反对。比方原来在微服务体系中服务注册、服务发现以及流量观测等能力是须要管控层面的主线去实现的。咱们能够通过治理 POD 中的流量以及数据层面的单点，让他们造成网状结构，变成一个集群。这个能力实现了流量的调配、平安、观测，有这些能力之后，它就组成了 Service Mesh。
图中的编程模型与函数计算相干
申请驱动是基于申请的动静弹性伸缩，并简化申请解决的这种逻辑。微服务的调用，从流量进来后，个别会通过 4 层或者 7 层的负载平衡，随后散发到不同的微服务实例；然而在同一个微服务实例过程的外部，个别会有两个逻辑。第一个是申请治理，它可能是一个 HTTP 服务器，或者是一些 Handler，也可能是一些队列治理，申请散发能力的组成。而这些组成最终会将这些申请提交到第二局部，即申请解决中，而申请解决就是开发者须要去真正实现的一些逻辑。
比如说 Java Go、Python，它们都有本人的一套申请治理逻辑。而后申请治理和申请解决之间造成强烈的耦合，这个实力它既蕴含申请的治理，又蕴含申请解决的逻辑。在这个架构下就不存在一个全局独立，且能够感知到申请以进行流量治理的管制层，只有到整个实例本身的解决层才如此解释申请。即使此时微服务实例曾经过载，也很难将再这个申请转发到其余的微服务实例上进行负载平衡。所以申请驱动这个零碎就是查数据、并解决这两个因素，而咱们就是在做申请驱动的一个解耦。
如图所示，首先内部零碎传输过去的申请会先进行标准化，会有一个适配器，标准化之后就会将其放在申请负载均衡器中，这个负载均衡器能够了解该申请自身的语义；而后它能够驱动并进行解决。当处理单元不够时，它能够通过管理器来进行扩容；而逻辑单元比拟多时，它还能够进行缩容，这样变造成了一个动静的治理，能够为开发者节约十分多的老本。
申请驱动模型：
• 申请标准化
• 申请路由
• 解决治理
将申请标准化、申请路由、解决治理等组合起来，其实便是 Serverless 的概念。开发者基本不须要去关怀 server，只须要去专一业务逻辑便能够。这其实也是微服务体系与平台化的 Serverless 架构交融的过程。阿里云的 FC（函数计算）和 SAE（利用引擎）都是以解决这些问题为外围的。
微服务 +Serverless 最佳实际
Serverless 其实通过了很多年的倒退，其理念最早能够追溯到 2012 年；而 2014 年，AWS 正式推出 Lambda，由此掀起了 Serverless 浪潮，但随后而来的是一段沉静的发展期。这种状况呈现的起因是为什么呢？总体来看是因为函数计算的开发模式与本来模式有十分大出入，它更适宜前端的，而不是 long running 模式的一些利用，它更偏差于一些基于申请的解决。因而一些须要长时间运行的服务，或利用架构，便不太可能享受到 Serverless 带来的弹性和降本提效的红利。
微服务架构的痛点
微服务的痛点就是稳定性。微服务带来了许多其余组件。例如服务发现、或是其余的一些工具类的产品。而这些在单体状况下会变得更加复杂化，因为整个架构变成网状结构。容器与容器平台，它其实在某些水平上是帮忙咱们承载微服务这部分的运维的，然而其自身，例如容器 K8S 它们都是存在肯定复杂性的。
如 K8S 的这个架构图，是非常复杂的，同时也存在一些痛点：
• 容器镜像部署形式差别
• K8S 组件运维的简单
• 学习老本
微服务比拟现实的一个状态就是开发者只须要去关怀架构中的业务零碎，其余的网关 CICD 公布零碎、验货流程，以及包含未付配套的注册核心、告警监控、剖析日志，这些统统都不需开发者再去放心，开发者只须要去关怀业务零碎。对于开发者来说是最有吸引力的便是不必扭转本来的开发方式的根底上只专一业务逻辑即可。
- 专一业务逻辑
- 不扭转原有开发方式
- 无需关怀与运维底层资源
- 具备弹性能力能够升高闲时老本
- 优良的工具链
总结
微服务体系在整个云计算倒退的时代，它有不同的事件。例如最开始部署就是传统的 IT 设施，像 IDC 这种机房，微服务提供的是动态的物理计算资源。什么叫动态物理资源资源？比如说咱们的一个服务器，有可能会造成资源的节约。
而后到了第二步就是云托管时代，就是咱们大家所熟知的 VM。在阿里的话就是 ECS，它能够提供弹性的计算资源，然而它没有一个本质的扭转，只是说资源上变成弹性，但它对于服务、微服务的一个部署，包含治理运维等实质上都没有太大变动。
然而到了第三阶段云原生时代，云平台、云服务都能够承当这些简单的运维操作、配置、治理。如微服务提供的就是一个运行环境与平台，此时用户只须要去关怀业务零碎、以及如何实现业务零碎即可。将简单的技术变得越来越简略，让用户不再感知那些烦杂的操作，由平台代替用户去做反复的、难以保护的工作，这也合乎整体计算机技术的倒退方向。