Microservices==;Service Mesh==;Serverless，走马观花

Posted 2021-08-14 KendoCross

[0] 始有道

话说图灵开天辟地，冯.诺伊曼造石补天！

始有道
道生ML 　　　　　　Machine Language
ML生汇编 　　　　　assembler
汇编生编译器 　　　 compiler
编译器生PL 　　　　Programming Language

后50年业务编程语言起，浩浩汤汤！
龟叔造Python,因为 人生苦短

 

 

 Rasmus 造php，因为 PHP 世界上

松本行弘，不是很高兴，因为他注意到其他程序员不是很高兴。他创建了 Ruby 来让程序员高兴。
Brendan Eich 利用周末时间设计了一门语言，三易其名。LiveScript==>javascript==>ECMAScript
James Gosling 发明了 Java，从此天下门生半数尽入其彀中
Anders Hejlsberg 重新发明了 Java 然后把它叫做 C#，人们都喜欢这个新版本的 Java，因为它完全不像 Java。

 

一时间百家争鸣、百花齐放，计算机江湖，风云突起，各种设计、架构、模式豪杰并起、层出不穷、群雄逐鹿、熙熙攘攘
夫天下大势分久必合、合久必分
系统架构莫不如是
且听小生慢慢道来

 

[1] 合久必分

起初项目比较小，系统功能不复杂，所有功能集成在一个项目工程中，所有功能打包成一个WAR包部署，应用服务与数据库服务分开部署，通过集群来提高系统性能，此乃单体架构！

优点：项目架构简单，前期开发成本低，周期短，小型项目的首选。
缺点：开发效率低，所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断
缺点：代码维护难，代码功能耦合在一起，新人不知道何从下手
缺点：部署不灵活，构建时间长，任何小修改必须重新构建整个项目
缺点：稳定性不高，一个微不足道的小问题，可以导致整个应用挂掉
缺点：扩展性不够，无法满足高并发情况下的业务需求
噫吁嚱！为之奈何？

——分而治之，微服务

 

 

 

那什么是微服务呢？
此处争议较多！
此处不可描述！
此处略去800字！
此处大家不要想歪了！
此处大家还是看图算了！

微服务的定义，没有共识，但常见微服务组件还是清晰的

服务注册：服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己。
服务网关：服务网关是服务调用的唯一入口，可以在这个组件是实现用户鉴权、动态路由、灰度发布、A/B 测试、负载限流等功能。
服务发现：服务调用方从服务注册中心找到自己需要调用的服务的地址。
配置中心：将本地化的配置信息（properties, xml, yaml 等）注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包的迁移。
API 管理：以方便的形式编写及更新 API 文档，并以方便的形式供调用者查看和测试。
负载均衡：服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。节点选择的工作对服务调用方来说是透明的。
分布式事务：对于重要的业务，需要通过分布式事务技术（TCC、高可用消息服务、最大努力通知）保证数据的一致性。
调用链：记录完成一个业务逻辑时调用到的微服务，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地找到出错点。
支撑平台：系统微服务化后，系统变得更加碎片化，系统的部署、运维、监控等都比单体架构更加复杂，那么，就需要将大部分的工作自动化。现在，可以通过 Docker、K8S等工具来中和这些微服务架构带来的弊端。 例如持续集成、蓝绿发布、健康检查、性能健康等等。

那微服务又有什么优缺点呢？

优点又很多，比如
降低系统复杂度：每个服务都比较简单，只关注于一个业务功能。
松耦合：微服务架构方式是松耦合的，每个微服务可由不同团队独立开发，互不影响。
跨语言：只要符合服务 API 契约，开发人员可以自由选择开发技术。
独立部署：微服务架构可以使每个微服务独立部署。开发人员无需协调对服务升级或更改的部署。
Docker 容器：和 Docker 容器结合的更好。
DDD 领域驱动设计：和 DDD 的概念契合，要两颗一起嚼才最好。

缺点也不少，如下
微服务强调了服务大小，但实际上这并没有一个统一的标准：业务逻辑应该按照什么规则划分为微服务，这本身就是一个经验工程。
微服务的分布式特点带来的复杂性：开发人员需要基于 RPC 或者消息实现微服务之间的调用和通信，而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的相当棘手。
分区的数据库体系和分布式事务：更新多个业务实体的业务交易相当普遍，不同服务可能拥有不同的数据库。CAP 原理的约束，使得我们不得不放弃传统的强一致性，而转而追求最终一致性，这个对开发人员来说是一个挑战。
测试挑战：传统的单体WEB应用只需测试单一的 REST API 即可，而对微服务进行测试，需要启动它依赖的所有其他服务。这种复杂性不可低估。
跨多个服务的更改：比如在传统单体应用中，若有 A、B、C 三个服务需要更改，A 依赖 B，B 依赖 C。我们只需更改相应的模块，然后一次性部署即可。但是在微服务架构中，我们需要仔细规划和协调每个服务的变更部署。我们需要先更新 C，然后更新 B，最后更新 A。
部署复杂：微服务由不同的大量服务构成。每种服务可能拥有自己的配置、应用实例数量以及基础服务地址。这里就需要不同的配置、部署、扩展和监控组件。此外，我们还需要服务发现机制，以便服务可以发现与其通信的其他服务的地址。

 

 

还有一个更大的槽点：目标接口、链路跟踪注入、日志引流、服务注册发现、路由规则等组件以及熔断、限流等功能都需要在应用服务上添加一些对接代码。如果让每个应用服务自己实现是非常耗时耗力的，而且也不符合DRY原则

可有良策？且听下回书“李代桃僵”

 

 

[2] 李代桃僵

K8S最小的调度单元为什么是Pod,而不是容器？
我不打算回答这个问题，因为我是

 

 ，我也不知道。主要记住pod有以下主要特点

 

 

 

 

 

 

 

 利用Pod的以下特点，我门可以把非业务功能，系统型的公共功能外包出去，交给“李子树”，此乃服务网格是也！

话不多说，上图

 

 

 

 

思考题：微服务，已经够微小了吗？这是个问题，Let us see see!

 

 

[3] 至小无内——Server less

 

 

 

 Server less主要有以下特征：

无常驻服务器，200MS内解决容器启动、请求接入

事件驱动

单事件处理

自动弹性伸缩

无状态开发

 

 思考题：服务还能更小吗？都小到一个函数了，难道还要小到0.1个函数？

[4]  分久必合

 既然不能再小了，不如更大、更高、更强？

 Istio 从1.5 开始，回归单体！

 

Segment从微服务回归单体！！

是轮回，是宿命，还是注定？看来果真天下大势分久必合、合久必分。

涛涛江水东流去，无法阻止，那只能随波逐流，看来是时候着手搭建一个ServiceMesh 实验室了！