Microservices==>Service Mesh==>Serverless，蜻蜓点水

[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 实验室了！