来源

《IT 老齐的架构 300 讲》

课件地址：https://manongbiji.oss-cn-beijing.aliyuncs.com/ittailkshow/it300/download/ppt_all_in_one.zip

【001】-聊一聊被培训机构神话的架构师

来源：https://www.bilibili.com/video/BV1WM4y1N79G?spm_id_from=333.999.0.0

架构师不是速成的，需要多年的沉淀，积累。
是多年技术沉淀的结果。

不谈场景的架构设计都是耍流氓
架构没有对不对，只有合不合适

思考：随着业务的发展，下面的单机架构性能瓶颈在大量文件的读写影响到磁盘 IO。怎么优化来应对这种情况？

新手架构师和老架构师的区别：内功。

新手架构师：增加 Redis。

缺点：
● 架构复杂度增加
● 新的数据一致性难题

老架构师调整方向：
● Web 容器层面增加拦截器阻挡垃圾重复无效的请求穿透到数据库
● 分析业务代码中 SQL 是否存在全表扫描以及索引选择性问题
● 增加 InnoDB 引擎的 Buffer_Pool 让查询拥有更多的缓存命中率
● 在操作系统层面，增加文件系统缓存，减少文件 IO 次数

框架与架构的区别：
● 架构是宏观设计的标准
● 框架是具体实现的规则

【041】视频一看就会，代码一写就废！？独家分享老齐高效的学习姿势！

来源：https://www.bilibili.com/video/BV1yq4y1Z7Ty?spm_id_from=333.999.0.0

1.先铺面再学点，学跑偏等于白搭
2.找个好师傅，脸皮要厚，不懂就问，比自己琢磨强
3.极致的实用主义，平时学实战，面试补源码
4.网上的都是虚拟的，只有你踩过坑，你才能更强大（头秃）
5.好脑子不如赖笔头，学会科学的做笔记

【017】老齐十七年开发与架构设计的一些感悟

没有场景的架构设计就是耍流氓

发现问题的复杂性是根本,这些包含在用户关键需求中

● 亚信为联通开发的系统用了12年的老系统,运行一切良好,但架构太过陈旧,目前已经没几个人懂这些技术
该复杂度来自于技术落后,如何把老技术重构为新架构

● XX银行之前外包公司开发的资产管理平台,因为研发人员对业务不熟悉,很多报表结果都是错误的
该复杂度来自于研发团队,加强业务培训,加强代码合规与测试粒度

● 万能表单应用允许用户自定义表单项,同时允许自定义表单业务逻辑
该复杂度来自于系统的可扩展性,可以考虑引入规则引擎

“解耦”是架构设计无时无刻考虑的事情

尊重”爬->走->跑->跳”的自然规律,好架构一定是演化而来的

千万不能为了”炫技”进行设计，否则整个公司要为之埋单

好的架构师一定是一个”聆听”的高手,跟客户交流要说人话

【010】什么是 CAP 定理

来源：https://www.bilibili.com/video/BV1a44y1C7Tx?spm_id_from=333.999.0.0

什么是 CAP 定理。
分布式架构的基本理论。
指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。

● 一致性 C 代表更新操作成功后，所有节点在同一时间的数据完全一致。
● 可用性 A 代表用户访问数据时，系统是否能在正常响应时间返回预期的结果。
● 分区容错性 P 代表分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务。

CAP 这三个要素最多只能同时实现两点，不可能三者兼顾。
所有只有 CP，AP，AC。

AP 表现为订单创建后不等待。库存减少直接返回处理结果。
CP 表现为订单创建后一直等待库存减少后才返回结果。
AC 表现为不再拆分数据系统，在一个数据库的一个事务中完成操作，也就是单体应用

当前场景：订单系统下单买了 1 瓶酒，库存系统酒的数量-1。

分布式系统中，系统之间需要网络通信等各种问题。无法实现买了 1 瓶酒，库存即时 -1。

CP：订单创建后，等待库存减少后才返回结果。保证数据一致，强一致性表现，用户体验差。（类似银行存钱）
AP：订单创建后，不等待库存减少后就返回结果。那库存数据怎么办？（异步处理后通知订单系统，若异步处理失败，有补偿机制（重新发请求，补录，校对程序）保证数据一致）。（类似淘宝）
AC：不拆分数据库系统，在一个数据库的一个事务中完成操作，即单体应用。下单，减库存在一个事务。缺点：不能做分区， 分区涉及网络，进而涉及分区容错性，进而选 CP,AP。

【011】关于负载均衡器，你学会（fei)了吗？

来源：https://www.bilibili.com/video/BV1rg411L7sg?spm_id_from=333.999.0.0

什么是负载均衡器？

● 高可用性
● 使每一台设备压力平均分配
● 支持故障发现与转移

负载均衡器有哪些类型？

硬件负载均衡，软件负载均衡

硬件负载均衡（F5）

网络层面

4 层代理（指网络 7 层模型（OSI）的传输层，TCP），举例：Linux 的 LVS
7 层代理（指网络 7 层模型（OSI）的应用层，HTTP），举例：Nginx

	四层负载均衡	七层负载均衡
功能性	少	多，支持资源压缩、更多策略
执行效率	高	相对较低
作用协议	TCP	HTTP、FTP、SMTP
应用场景	实时应用集群 大规模集群间数据交互	Web 应用集群 需要更多额外功能的应用集群

Nginx 是一款轻量级的 Web 反向代理服务器。
是目前使用最多的软件负载均衡器

负载均衡策略有哪些？

Nginx 五种负载均衡策略

负载均衡策略	描述1	描述2
轮询策略（默认）	4 个任务，你负责 1，我负责 2，你负责 3，我负责 4。 适用于性能相当的服务器。	排排坐吃果果，你一口我一口
权重策略	4 个任务，你能力强，你做 3 个，我能力差，我做 1 个。 适用于性能不一致的服务器	我比你胖，我要吃十个
IP_HASH	有多个用户访问 Nginx，通过用户的 IP 对 N 取模（N 台服务器） 该 IP 一直由对应的服务器负责。 不建议使用，无法保证服务器的均衡。	一个萝卜（IP)一个坑
URL_HASH（三方）	类似 IP_HASH，比 IP_HASH 更精确，但仍无法保证服务器的均衡	一个白菜（URL)一个坑
FAIR（三方）	谁有空谁干活。 使用心跳包判断哪台服务器闲置，然后把请求送达闲置服务器。 现实使用较少。了解即可	你们谁闲着，出来挑粪去

【013】前后端分离架构到底做了啥，让互联网项目情有独钟？

来源：https://www.bilibili.com/video/BV14h411B7dE?spm_id_from=333.999.0.0

纯后端页面渲染架构

缺点：
● 前端团队无法单独调试
● 前后端职责不清，分工不明
● 不具备多端应用的潜力

前后端分离

确保数据与应用解耦

半分离架构模式

优点：
● 前后端团队解耦
● 后端 API 与数据重用
● 应用渲染更灵活
● 约定好接口与规范进行 Mock 开发

缺点：
● 前端失去动态性
● 搜索引擎 SEO 不友好

【053】单页 10 万 QPS，京东如何通过动静分离架构抗住超高并发访问

来源：https://www.bilibili.com/video/BV1QL411W7xz?spm_id_from=333.999.0.0

VKER-cc:现在有一个新的研究方向，估计你会很感兴趣，也可能你会听过:vert.x，graalvm，quarkus，java 下的云原生，这几天我在研究，可是这货属于起步阶段，除了官网有相对晦涩的英文描述，国内除了个 demo 就搜不到什么了，要不你试试？我感觉基于 quarkus 的云原生就是下一代的应用底层部署方式。
IT老齐：这个太鸡儿超前了。 我会持续观察，目前我把注意力放在 ServiceMesh = Istio上，这是个好东西，感觉明天这个要火

架构三大分离设计
● 读写分离
● 动静分离
● 前后台分离

动静分离优化原理

● 静态数据是”无个性化”数据
—-· 静态文件: HTML/CSS/JS/图片
—-· 低频变动数据: 字典数据 / 地区数据 / 组织架构 / 历史数据
● 动态数据就是个性化/高频写数据
—-· 个性化推荐
—-· 高频写: 股市行情 / 5G 信号数据 / 天气变化
● 有效区分页面中的动静数据是优化的关键前提

动静案例演练

为什么使用动静分离？
● 静态页面处理需要几毫秒
● 动态页面生成需要几百毫秒
● 如何将动态页面生成到静态页?

页面静态化技术

● 将动态页面”另存为”静态页面保存到本地磁盘
● 利用 Nginx 直接路由到磁盘文件,不再进入后端
● 文件碎片化严重,文件同步管理麻烦

页面伪静态化技术(推荐)

● 利用 Redis 缓存,缓存生成的页面
● 没有碎片化问题,可自动过期,数据管理轻松
● 需要大量内存存储信息

总结

一.静态化不是万能的

● 静态化只适合数据集有限(百万量级)的场景
—-· 热点商品SKU
● 页面集过大不适合静态化
—-· 商品全量 SKU,文件碎片太多
—-· 批量同步磁盘 IO瓶颈
—-· 伪静态化内存开销太大
● 动态内容是静态化遇到的新挑战

二.动静整合方案

1.服务端 SSI 法
—-· 利用 Nginx SSI 特性实现服务端动静整合

SSI 是 Server Side Inclde 的缩写，是一种基于服务端的网页制作技术，就是服务端包含的意思，该项目中用到了 nginx 中 SSI 模块的 include 命令，这个命令会包含一个页面，然后在 nginx 服务器中展开。

案例：京东动静结合方案

示意: http://item.jd.com/1101.html

<html>
  <body>
    <!--# include file="/static/cal-1101.html" -->
    <!--# include file="/static/title-1101.html" -->
    <!--# include file="/dynamic/pro/1101" -->
    <!--# include file="/static/sku-1101.html" -->
  </body>
</html>

2.Ajax 异步调用法
—-· 生成静态页面,动态数据部分发起 Ajax 异步查询

示意: http://item.jd.com/1101.html
<html>
  <body>
    <div>轮播HTML代码...<div>
    <div>标题HTML代码...<div>
    <div id='promotion'></div>
    <div>SKU HTML代码...<div>
    <script>
        $.ajax({
            url : '/dynamic/pro/1101',
            success : 根据返回JSON组织活动HTML
        })
    </script>
  </body>
</html>

【027】分享一套炒鸡经典的 Web 高可用架构

来源：https://www.bilibili.com/video/BV1nU4y1j7ct?spm_id_from=333.999.0.0

上古 DNS 轮询也有妙用

DNS 轮询的缺点

● 只负责 IP 轮询获取,不保证节点可用
● DNS IP 列表变更有延时
● 外网 IP 占用严重
● 安全性降低

DNS 轮询 与多 VIP 组合解决利率用问题

安全层面: 做好DNS劫持的预防
设备方面: 2 * Nginx+ N * Tomcat + 1 * MySQL

【031】从宜信架构演化理解微服务架构设计

来源：https://www.bilibili.com/video/BV1Uq4y1K7dd?spm_id_from=333.999.0.0

了解分布式架构的发展过程
到底怎么才能算微服务架构
宜信落地的分布式架构体系

单体阶段

● 紧耦合
● 系统复杂，牵一发动全局
● 所有模块耦合在一个进程中
● 完全封闭架构
● 业务发展初期，快速满足客户需求

垂直拆分阶段

● 紧耦合
● 垂直拆分系统，竖井式架构子系统之间没有直接关联重复造轮子∶ OS，DB， Midderware
● 存在大量的重复代码拷贝
● 完全封闭架构业务
● 快速增长时，以应用系统为中心的架构模式

RPC 通信阶段

RPC（Remote Procedure Call）远程过程调用，简单的理解是一个节点请求另一个节点提供的服务

● 紧耦合（共享分布式对象实现远程方法调用））
● 系统交互采用RPC私有TCP协议
● 服务生产者消费者存在强代码依赖
● 异构系统集成不友好
● 高并发场景，性能比较好

ESB 服务总线阶段

● 松耦合
● ESB 消息总线技术实现异构系统集成集中式架构管理
● 基于 WebService 技术，重量级的消息通讯机制
● 业务功能重用，粒度粗
● 智能管道哑终端
● 面向服务架构，团队规模大时，集成异构系统，提供统一服务解决方案。

微服务阶段

所谓微服务架构风格是一种将单个应用程序开发为一组小型服务的方法，每个小服务运行在自己的进程中，并以轻量级的机制(通常是HTTP RESTful API)的方式进行通信，这些服务围绕着业务能力所建立的，并且可以由完全自动化的部署机构独立部署，这些服务的集中管理只有最低限度，可以用不同的编程语言编写并使用不同的数据库存储技术。
————詹姆斯·里维斯 & 马丁·弗勒

【056】日千万级订单系统的高可用、高性能架构该如何设计

来源：https://www.bilibili.com/video/BV1kU4y1c75e?spm_id_from=333.999.0.0

【IT老齐056】日千万级订单系统的高可用、高性能架构该如何设计.zip

【060】在分布式架构开发时 N 点血的教训，与君共勉！

来源：https://www.bilibili.com/video/BV1jf4y1c7TZ?spm_id_from=333.999.0.0

什么是分布式架构？

分布式系统是将一个大的系统打散成很多个小系统、小服务，再由多个团队协作完成共同的目标。现在以微服务架构为代表的分布式系统大行其道，至于微服务的好处我在这就不多赘述，比如：更小的管理粒度、独立的数据存储、统一的通信标准等等，今天咱们就聊一聊以微服务为代表的分布式系统设计时有哪些坑吧！

在著名软件著作《人月神话》中提到，软件世界没有“银弹”，这句话当然适用于架构领域，随着从单体架构过度到微服务架构，因为将原有系统打散，给系统增加了许多不稳定因素。

下面我从网络、性能、运维成本、组织架构与集成测试五个方面分别进行阐述。

微服务架构五个方面的不稳定因素

网络

第一点，以往单体应用是在单机中进行进程内通信，通信稳定性相当好。但是打散为分布式系统后，变为进程间通信，往往这个过程还伴随着跨设备的网络访问，架构师在设计时必须考虑上下游系统因为网络因素无法通信的情况，要假设网络是不可靠的，并设计微服务在网络异常时也能进行符合预期的异常处理。

以支付模块为例，用户支付成功后系统自动调用短信服务向用户手机发送“订单支付成功”的消息，此时架构师就必须假设短信服务在服务或者网络不可用时不会影响到订单业务的正常执行。

性能

第二点，相比传统单体架构进程内通信，跨进程、跨网络的微服务通信在网络传输与消息序列化带来的延迟是不可被忽略的，尤其是在五个以上微服务间消息调用时，因为网络延迟对于实时系统的影响是是很大的。

早些年我和一个军事院校合作了一个雷达仿真训练的系统，因为要模拟”导弹打飞机”的场景，在计算飞行轨道时 1 毫秒的响应增加都可以会影响到最终的结果，显然这类系统采用分布式设计就不再合适。

运维成本

第三点，运维成本会直线上升，早期单体应用因为结构简单，规模也较小，发版时通常面对几台服务器部署几个 Jar/War 文件就可以了。

同时，应用的交付周期也是以周甚至月为单位，此时硬件设备成本与运维人员技术要求都比较低，采用手动部署即可满足要求。

而对于微服务架构而言，每一个服务都是可独立运行、独立部署、独立维护的业务单元，再加上互联网时代用户需求的不断变化以及市场的不稳定因素，运维人员每天面对成百上千台服务器发布几十次已是家常便饭，传统手动部署显然已经无法满足互联网的快速变化。

组织架构

第四点，组织架构层面的调整，微服务不但是一种架构风格，同样也是一种软件组织模型，以往软件公司会按照职能划分，如：研发、测试、运维部门进行独立管理考核，而在微服务的实施过程中，以业务模块进行划分团队，每一个团队是内聚的，要求可以独立完成从调研到发版的全流程，尽量减少对外界的依赖。如何将传统的职能团队调整为按业务划分组织架构，同样是对管理者的巨大挑战，要知道人的思想比架构更难改变。

集成测试

第五点，服务间的集成测试变得举步维艰，传统单体架构集成测试是将不同的模块按业务流程进行组合，在进程内验证每一种可能性下其模块间协作是否符合预期即可。但对于微服务而言，系统被拆解为很多独立运行的单元，服务件采用接口进行网络通信。要获取准确的测试结果，必须搭建完整的微服务环境，光这一项工作就有很大的工作量。同时，因为是跨网络通信，网络延迟、超时、带宽、数据量等因素都将影响最终结果，测试结果易产生偏差。

N 条微服务架构的最佳实现

第一点，微服务的划分原则。

将已有系统拆分为多个微服务，本就没有统一的标准。
举个例子，一个初创型电商公司，要开发一套电商系统，将“促销活动”单独剥离出来作为”促销服务”是没有问题的。
但是如果你在“淘宝”、“京东”这种体量的电商平台，”促销服务”就显得粒度太粗，可以继续拆解为”价格服务”、”优惠券服务”、“京豆服务”等更细 粒度的小服务，每个服务有专门团队负责维护。

因此，在微服务实践过程中，我们通常会从业务场景、团队能力、组织架构等多种因素综合考虑，这特别考验架构师的业务能力。一般来说，我们总结出几点通用原则：

● 单一职责原则，每一个微服务只做好一件事，体现出“高内聚、低耦合”， 尽量减少对外界环境的依赖。比如，在公司创业之初，完全可将订单与仓储服务进行合并。因为订单与仓储在业务与数据紧密相关，如果强行拆分会导致出现跨进程通信 带来的数据一致性难题。随着业务的发展，仓储的业务职责扩展，派生出许多与订单 无紧密联系的功能，到时再将其剥离形成独立的“仓储服务”也不晚。

● 服务依赖原则，避免服务间的循环引用，在设计时就要对服务进行分级，例如区分核心服务与非核心服务。例如订单服务与短信服务，显然短信服务是非核心服务，服务间调用要遵循“核心服务”到“非核心服务”，不允许出现反向调用。同时，对于核心服务要做好保护，避免非核心服务出现问题影响核心服务的正常运行。

● Two Pizza 原则，就是说让团队保持在两个比萨能让队员吃饱的小规模的概念。团队要小到让每个成员都能做出显著的贡献，并且相互依赖，有共同目标，以及统一的成功标准。一个微服务团队应涵盖从需求到发布运维的完整生命周期，使团队 内部便可以解决大部分任务，从人数上 4~6 人是比较理想的规模。

第二点，为每一个微服务模块明确使命

这里推荐一套标准的微服务叙述模板，集中体 现“只做好一件事”的原则。

模板 
XX微服务用来 
在出现痛点场景的情况下 
解决现有的XX问题 
从而达到了XXX的效果 
提升了微服的价值 
============================================== 
示例 
商品检索微服务用例 
在商品数据全量多维度组合查询的情况下 
解决了 MySQL 数据库全表扫描查询慢的问题 
从而让查询响应降低到 50ms 以下 
有效提升了用户体验

通过这种描述，服务的职责与边界就十分明确，团队变以此为目标确认的职责。在实施过程中因为我们是以解决问题为目标，切分时可能会比较细碎。经过漫长时间沉淀，系统中 出现了”商品检索服务”、”订单检索服务”、”商铺检索服务”等小服务，这时可以对这个服务形成聚合生成新的”通用检索服务”，以此来控制微服务的整体规模。反之，对于庞大的服务，可以考虑拆分为多个小服务进行细粒度的管理，总之拆与合是伴随着公司业务的演进而变化的，一切以解决问题为准

第三点，微服务确保独立的数据存储

数据是任何系统最重要的资产。以往单体应用通常会选择 MySQL 这种关系型数据库作为数据的统一存储，这样做的好处是涉及多表操作时，利用数据库自带的事务机制便可最大程度保证数据完整性。但这样做却存在诸多问题， 以下图为例，不同的微服务对数据存储的需求也是不同的，订单服务需要 MySQL 数据保存订单与订单明细；新闻服务需要 Elasticsearch 提供全文检索支持；朋友圈需要图数据库表达现实世界人际关系；文件存储服务则需要分布式文件系统。如果将所有数据都揉在 MySQL 中使用会变得十分蹩脚，好的做法是为每一个微服务提供符合自身业务特性的数据库。

但理想很丰满现实很骨感，在分库后涉及到跨库操作会变难以处理。比如，订单依赖会员数据，原始单库处理时一条 SQL 语句便可实现。

SELECT order.* , member.* 
FROM order,member 
WHERE order.member_id = membe r.member_id

但在微服务架构下，因为数据库绝不允许其他团队访问，关联查询只能变为 API 调用形式，程序实现层面比单库复杂不少。

与之类似，如果涉及到多表写入时一致性问题更复杂。

BEGIN ; 
写入表A; 
写入表B; 
COMMIT;

但拆分为服务后，数据被分散到多库，为保证异构多库的数据一致性是所有分布式应用的巨大挑战，至今没有完美的解决方案。

第四点，服务间通信优先采用聚合器模式

在微服务间通信时存在两种消息传递模 式“链式模式”与“聚合器模式”。下图是所示，按业务流程请求在各个服务间流转，最终处理完成返回客户端。

因为请求是按业务流程传递，很容易能被开发人员理解，因此链式模式称为了最常用的服务间通信模式。但链式模式采用串联模式，调用整个成功率等于服务调用成功率的乘积， 假设每个服务可靠性为 90%，一个业务代码在 4 个服务执行后的最终成功率只有 90% *90% *90% * 90% ≈ 66%，有将近一半的请求会处理失败，这是无法接受的。此外，链式模式因默认采用同步方式传输，在服务处理完成前请求会一直处于阻塞状态，当调用链较长时，系统整体性能会严重下滑。

聚合器模式则是通过服务作为入口，组装其他服务的调用，因为“订单流程服务”是将其他服务进行聚合操作，所以称其为聚合器模式。以“订单流程服务”为例，将“订单”、“支付”、“库存”服务进行聚合，一个服务实现从下单、支付、减库存的完整流程

采用聚合器模式后，业务流程与编排集中在“订单流程服务”中，可对整体业务进行有效编排，支付与扣库存是可以并行调用，可以有效提高系统的性能。

第五点，一定要务实，不要强行“微服务”化

在以前公司任职时因为业务需要，要开发一个工单系统用来售后人员在线为客户提供售后服务，但当时因为公司产品已经非常成熟，每天产生的工单只有几十笔，如果做成单体应用配合 Nginx 反向代理，从存储到应用便能满足需求。任务分配给一位“年轻”的架构师，可能是为了证明实力，他采用的全套微服务来”炫技”，并在会议上侃侃而谈。结果老板反问他”你这么设计有必要么，为一个工单系 统投入超过 10 台服务器成本你考虑了吗?” ，当时那场景别提多尴尬了。其实在我看来，微服务也不过是一种方案，没必要盲从。它没有违背架构的基本规律: 架构是解决当前需求和痛点而演进的。在满足需要的前提下，选择合适的而不是选择最好的，合理降低成本才是好架构师该考虑的事情。

适合做微服务的系统

以上微服务的经验都是我在实际工作中总结归纳出来的，如有不足的地方欢迎同学们在评论中给予补充，在本文最后一部分，我也为你总结了适合微服务使用场景，首先咱们梳理下适合做微服务的系统。

● 新规划的大型业务系统， 这肯定是最适合引入微服务架构的情况了，微服务强 调”高内聚，低耦合”，每一个团队负责一个服务，这就意味着从根上和传统的整体性应用有本质不同。从规划阶段采用微服务架构是再好不过的。

● 敏捷的小团队系统，在公司在大型项目微服务实践前，往往这类边缘化的小项目会起到”试验田”的作用， 引入快速迭代、持续交付等开发模式，积累适合本公司特点的微服务实践经验，在将这些经验扩大到其他大型项目中。

● 历史的大型留存业务系统，之前多年我一直在金融软件领域工作，在银行内部许多系统已经使用超过 10 年时间，长百上千个模块错综复杂维护愈发苦难，无论架构、 框架乃至技术人员都需要更新迭代，但都不可能一次大动手术，这是微服务的”微”就体现出来，重构时可以将某一个部分剥离为微服务独立运行，确保无误后再继续剥离出下一个服务，通过抽丝剥茧一般的剥离，逐步将原有大系统剥离为若干子服务，虽然过程十分痛苦，但这是必须做的事情。至于这个如何实现在后面的课程中我们会专门讲解。

不适合引入微服务的场景

下面咱们再来列举几个不适合引入微服务的场景

● 微型项目，类似于前面提到的工单系统，系统压力很小，需求变化也不大，利用单体架构便可以很好解决，使用分布式架构反而增加了架构复杂度，让系统反而容易不稳定。

● 对数据响应要求高的系统，就像前面文中提到的“导弹打飞机”的科研项目，对实时性要求极高，那显然是不合适的。

【064】上了微服务就能高并发？扯淡，几张图给你讲明白微服务架构的作用

来源：https://www.bilibili.com/video/BV1q44y1v7S9?spm_id_from=333.999.0.0

微服务架构帮我们解决了什么问题？

问题

微服务的定义

所谓微服务架构风格是一种将单个应用程序开发为一组小型服务的方法，
每个小服务运行在自己的进程中，并以轻量级的机制(通常是 HTTP RESTful API)的方式进行通信,
这些服务围绕着业务能力所建立的，并且可以由完全自动化的部署机构独立部署，
这些服务的集中管理只有最低限度，可以用不同的编程语言编写并使用不同的数据库存储技术

改造后的微服务架构

规避大一统的架构设计

【067】不作不死，微服务架构，没做好准备千万别碰！

来源：https://www.bilibili.com/video/BV1oR4y1J7vJ?spm_id_from=333.999.0.0

微服务架构有什么问题

什么才叫“微”服务，每个架构师心中的哈姆雷特

业界是没有标准答案的

分布式一致问题，有解决方案吗？

炒鸡恐怖的调用链，你能 Hold 住吗？

容器编排与 DevOps 流水线，你准备好了吗？

团队和预算，你准备了多少？

什么情况才适合引用微服务架构

1.试验性质的边缘应用，做技术沉淀
2.预算充足，从零起步的新项目
3.拥有明确业务边界的技术团队

千万不要盲目轻信某大佬说的,
老项目很容易向微服务进行迁移,
只要做过就知道里面有多恶心了!