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

Microservices==>Service Mesh==>Serverless,走马观花的更多相关文章

  1. 微服务(Microservices)和服务网格(Service Mesh)架构概念整理

    注:文章内容为摘录性文字,自己阅读的一些笔记,方便日后查看. 微服务(Microservices) 在过去的 2016 年和 2017 年,微服务技术迅猛普及,和容器技术一起成为这两年中最吸引眼球的技 ...

  2. 微服务(Microservices)和服务网格(Service Mesh)的架构概念

    注:文章内容为摘录性文字,自己阅读的一些笔记,方便日后查看. 微服务(Microservices) 在过去的 2016 年和 2017 年,微服务技术迅猛普及,和容器技术一起成为这两年中最吸引眼球的技 ...

  3. 浅谈服务治理、微服务与Service Mesh(三) Service Mesh与Serverless

    作为本系列文章的第三篇(前两篇<浅谈服务治理.微服务与Service Mesh(一)Dubbo的前世今生>,<浅谈服务治理.微服务与Service Mesh(二) Spring Cl ...

  4. What’s a service mesh? And why do I need one?

    https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/ Update 2018-02-06: Since t ...

  5. 蚂蚁金服 Service Mesh 实践探索

    SOFAMesh是蚂蚁金服在ServiceMesh方向上的探索,下面是它高级技术专家敖小剑在QCon上海2018上的演讲. Service Mesh 是一个 基础设施层,用于处理服务间通讯.现代云原生 ...

  6. 解读2017之Service Mesh:群雄逐鹿烽烟起

    https://mp.weixin.qq.com/s/ur3PmLZ6VjP5L5FatIYYmg 在过去的2016年和2017年,微服务技术得以迅猛普及,和容器技术一起成为这两年中最吸引眼球的技术热 ...

  7. 下一代微服务 ~ Service Mesh

    微服务(Microservices) 微服务(Microservices)是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成.系统中的各个微服务可被独立部署,各个微服务之间是松耦合的.每个微服 ...

  8. 蚂蚁金服 Service Mesh 渐进式迁移方案|Service Mesh Meetup 实录

    小蚂蚁说: 本文是基于在 Service Mesher Meetup 上海站的主题分享<蚂蚁金服 Service Mesh 渐进式迁移方案>内容整理,完整的分享 PPT 获取方式见文章底部 ...

  9. Service Mesh是什么技术

    https://blog.csdn.net/weixin_38044696/article/details/80257488 Service Mesh是什么技术 2018年05月09日 22:07:4 ...

随机推荐

  1. 六QT使用mqtt

    QT官方的mqtt是qmqtt,头文件是 #include <qmqttclient.h> 官方的文档地址 https://doc.qt.io/QtMQTT/qmqttclient.htm ...

  2. 30、LNAP(php和nginx相关优化)

    30.1.php-fpm.conf参数优化: [global] pid = run/php-fpm.pid #php后台运行pid路径 error_log = log/php-fpm.log #php ...

  3. 42、sort命令

    排序和把相同的放到一起: 42.1.sort命令介绍: sort命令是一个排序介绍,简而言之就是以什么为分割符,对第几列进行什么排序操作: 42.2.sort命令参数介绍: -u #去重,会直接把重复 ...

  4. 41、mysql数据库(存储过程)

    0.创建表: (1)建表: CREATE TABLE blog ( id INT PRIMARY KEY auto_increment, name CHAR(64), sub_time datetim ...

  5. layui tabs选项卡 响应试不显示问题

    添加: var element = layui.element; //Tab的切换功能,切换事件监听等,需要依赖element模块 element.init();

  6. 『无为则无心』Python函数 — 26、Python函数参数的传递方式

    目录 1.位置参数 2.关键字参数 3.缺省参数(默认参数) 4.不定长参数(可变参数) (1)包裹位置传递 (2)包裹关键字传递 5.位置参数.默认参数.可变参数的混合使用 6.拓展:参数解包 提示 ...

  7. webpack(8)vue组件化开发的演变过程

    前言 真实项目开发过程中,我们都是使用组件化的去开发vue的项目,但是组件化的思想又是如何来的呢?下面就从开始讲解演变过程 演变过程1.0 一般情况下vue都是单页面开发,所以项目中只会有一个inde ...

  8. Log4cpp配置文件及动态调整日志级别的方法

    一.log4cpp概述 Log4cpp是一个开源的C++类库,它提供了C++程序中使用日志和跟踪调试的功能,它的优点如下: 提供应用程序运行上下文,方便跟踪调试: 可扩展的.多种方式记录日志,包括命令 ...

  9. 「AGC020D」 Min Max Repetition

    「AGC020D」 Min Max Repetition 传送门 首先这个东西的连续字符个数你可以二分.但事实上没有必要,这是可以直接算出来的. 即 \(k=\max\{\lceil\frac{A}{ ...

  10. Java中为什么notify()可能导致死锁,而notifyAll()则不会(针对生产者-消费者模式)

    1.先说两个概念:锁池 和 等待池 锁池:假设线程A已经拥有了某个对象(注意:不是类)的锁,而其它的线程想要调用这个对象的某个synchronized方法(或者synchronized块),由于这些线 ...