架构
文章平均质量分 91
续亮~
哦
展开
-
19、架构-虚拟化容器
本文讲解虚拟化容器技术的发展及其在现代计算架构中的应用。内容分为三个主要部分:容器的崛起、以容器构建系统、以应用为中心的封装。以下是对每个知识点的详细描述。通过容器技术的不断发展和创新,现代计算架构在灵活性、可扩展性和可靠性方面取得了显著进步。从chroot到cgroups和namespaces,再到Docker和Kubernetes,容器技术为构建高效的分布式系统提供了坚实的基础。原创 2024-06-18 23:42:15 · 546 阅读 · 0 评论 -
18、架构-可观测性之聚合度量
除了常见的应用级和系统级指标,还可以根据具体需求定义和收集自定义的指标数据。例如,在电商系统中,可以收集每分钟的订单数、每秒的支付成功率等业务指标。原创 2024-06-17 09:35:21 · 705 阅读 · 0 评论 -
16、架构-可观测性-事件日志详细解析
事件日志是分布式系统可观测性的重要组成部分。通过科学合理的日志输出、收集、缓冲、加工、聚合和存储查询,可以实现对系统运行状态的实时监控和问题排查。上述方法和技术,不仅适用于大规模分布式系统,也可以为中小型系统提供有效的解决方案。通过实际案例的分析,可以看到这些技术在提升系统可观测性方面的显著效果,为系统的稳定运行保驾护航。原创 2024-06-14 23:12:54 · 868 阅读 · 0 评论 -
17、架构-可观测性-链路追踪详细解析
链路追踪是分布式系统可观测性的重要组成部分。通过科学合理的追踪和数据收集,可以实现对系统请求流转过程的实时监控和分析。原创 2024-06-14 23:29:54 · 859 阅读 · 0 评论 -
15、架构-可靠通讯之服务安全
我们已经了解了与具体架构形式无关的业界主流安全概念和技术标准(如TLS、JWT、OAuth 2等概念),在上一章节探讨了与微服务运作特点相适应的零信任安全模型。在本节中,我们将从实践和编码的角度出发,介绍在微服务时代(以Spring Cloud为例)和云原生时代(以Istio over Kubernetes为例)分别如何实现安全传输、认证和授权。通过这两者的对比,我们将探讨在微服务架构下如何将业界的安全技术标准引入并实际落地,实现零信任网络下安全的服务访问。原创 2024-06-11 23:20:32 · 771 阅读 · 0 评论 -
13、架构-流量治理之流量控制
任何一个系统的运算、存储、网络资源都不是无限的,当系统资源不足以支撑外部超过预期的突发流量时,便应该有所取舍,建立面 对超额流量自我保护的机制,这个机制就是微服务中常说的“限 流”。最大处理能力为80TPS的系统遇到100 TPS的请求时,应该能完成其中的80TPS,也即有20 TPS的请求失败或被拒绝才对,这是最理想的情况,也是我们追求的目标。原创 2024-06-10 22:39:30 · 954 阅读 · 0 评论 -
12、架构-流量治理之服务容错
容错性设计(Design for Failure)是微服务的另一个核心原 则,也是笔者书中反复强调的开发观念转变。不过,即使已经有一定 的心理准备,大多数首次将微服务架构引入实际生产系统的开发者, 在服务发现、网关路由等支持下,踏出了服务化的第一步以后,很可 能仍会经历一段阵痛期,随着拆分出的服务越来越多,随之而来会面 临以下两个问题的困扰。本章我们将围绕以上两个问题,提出服务容错、流量控制等一系列解决方案。原创 2024-06-08 22:04:50 · 895 阅读 · 0 评论 -
11、架构-从类库到服务之客户端负载均衡
客户端负载均衡(Client-Side Load Balancing)是指将负载均衡的逻辑从服务器端转移到客户端,使得客户端在发送请求之前决定将请求发送到哪个服务实例。这种模式相较于传统的服务器端负载均衡有许多优点,例如减少网络开销、避免单点故障等。在传统的服务器端负载均衡模式下,所有的请求都先发送到一个负载均衡器,由它来决定将请求转发到哪个服务实例。这种方法的缺点是负载均衡器本身可能成为单点故障,且在高并发场景下容易成为系统瓶颈。原创 2024-06-07 23:44:33 · 1144 阅读 · 0 评论 -
10、架构-从类库到服务之网关路由
网关路由在分布式系统和微服务架构中扮演着至关重要的角色。它不仅作为不同服务之间的通信桥梁,还承担着流量管理、安全控制和其他重要职能。路由:将外部请求路由到内部服务。网关根据预定义的规则或策略,决定如何处理和转发客户端请求。安全性:提供身份验证和授权控制。通过集成OAuth、JWT等机制,确保只有经过认证和授权的用户才能访问服务。流量管理:实现负载均衡、限流等功能。通过智能路由和流量分配,优化系统资源使用,防止单点过载。监控:记录和分析请求和响应数据。通过日志和监控系统,提供系统健康状态和性能指标。原创 2024-06-07 00:06:35 · 1125 阅读 · 0 评论 -
9、架构-从类库到服务之服务发现
微服务架构的一个重要设计原则是“通过服务来实现独立自治的 组件”(Componentization via Service),强调应采用“服务” (Service)而不是“类库”(Library)来构建组件化的程序,这两 者的差别在于类库是在编译期静态链接到程序中的,通过调用本地方 法来使用其中的功能,而服务是进程外组件,通过调用远程方法来使 用其中的功能。原创 2024-06-06 23:34:59 · 684 阅读 · 0 评论 -
8、架构-分布式的共识之Paxos+Raft+ZAB
在正式探讨分布式环境中面临的各种技术问题和解决方案前,我 们先把目光从工业界转到学术界,学习几种具有代表性的分布式共识 算法,为后续在分布式环境中操作共享数据准备好理论基础。下面笔 者从一个最浅显的场景开始,引出本章的主题:如果你有一份很重要的数据,要确保它长期存储在电脑上不会丢 失,你会怎么做?这不是什么脑筋急转弯的古怪问题,答案就是去买几块硬盘,在 不同硬盘上多备份几个副本。原创 2024-06-02 21:44:41 · 700 阅读 · 0 评论 -
7、架构-架构的安全性
我们从JWT令牌的一小段“题外话”来引出现代密码学算法的三种 主要用途:摘要、加密与签名。JWT令牌携带信息的可信度源自于它是 被签过名的信息,是令牌签发者真实意图的体现,因此是不可篡改 的。然而,你是否了解签名具体做了什么?为什么有签名就能够让负 载中的信息变得不可篡改和不可抵赖呢?要解释数字签名(Digital Signature),必须先从密码学算法的另外两种基础应用“摘要”和 “加密”说起。摘要也称为数字摘要(Digital Digest)或数字指纹(Digital Fingerprint)。原创 2024-06-01 21:51:11 · 1293 阅读 · 0 评论 -
6、架构-服务端缓存
为系统引入缓存之前,第一件事情是确认系统是否真的需要缓 存。从开发角度来说,引入缓存会提 高系统复杂度,因为你要考虑缓存的失效、更新、一致性等问题;从运维角度来说,缓存会掩盖一些缺 陷,让问题在更久的时间以后,出现在距离发生现场更远的位置上;从安全角度来说,缓存可能会泄漏某些保密数据,也是容易受到攻击 的薄弱点。冒着上述种种风险,仍能说服你引入缓存的理由,总结起 来无外乎以下两种。原创 2024-05-29 23:34:12 · 1260 阅读 · 0 评论 -
5、架构-负载均衡
在互联网时代的早期,网站流量还相对较小,业务也相对简单, 单台服务器便可满足访问需要,但时至今日,互联网应用也好,企业 级应用也好,一般实际用于生产的系统,几乎都离不开集群部署。信 息系统不论是单体架构多副本还是微服务架构,不论是为了实现高可 用还是为了获得高性能,都需要利用多台机器来扩展服务能力,希望 用户的请求不管连接到哪台机器上,都能得到相同的处理。原创 2024-05-29 23:10:35 · 1405 阅读 · 0 评论 -
4、架构-透明多级的分流服务
客户端缓存机制通过减少重复数据传输,提高了网络性能。强制缓存通过时间有效性假设,协商缓存通过变化检测机制,二者互补,共同实现了HTTP协议下高效的缓存管理。这些缓存机制是透明多级分流系统的一部分,提升了分布式系统的性能和可靠性。原创 2024-05-19 00:33:03 · 1007 阅读 · 0 评论 -
3、架构-事务处理
事务处理几乎在每一个信息系统中都会涉及,它存在的意义是为 了保证系统中所有的数据都是符合期望的,且相互关联的数据之间不 会产生矛盾,即数据状态的一致性(Consistency)。按照数据库的经 典理论,要达成这个目标,需要三方面共同努力来保障。以上四种属性即事务的“ACID”特性,但笔者对这种说法其实不 太认同,因为这四种特性并不正交,A、I、D是手段,C是目的,前者 是因,后者是果,弄到一块去完全是为了拼凑个单词缩写。事务的概念虽然最初起源于数据库系统,但今天已经有所延伸, 不再局限于数据库本身了。原创 2024-05-15 00:10:31 · 1130 阅读 · 1 评论 -
2、架构-服务间的通信
远程服务将计算机程序的工作范围从单机扩展至网络,从本地延 伸至远程,是构建分布式系统的首要基础。而远程服务又不仅仅是为 分布式系统服务的,在网络时代,浏览器、移动设备、桌面应用和服 务端的程序,普遍都有与其他设备交互的需求,所以今天已经很难找 到没有开发和使用过远程服务的程序员了,但是没有正确理解远程服 务的程序员却不少。原创 2024-05-14 22:46:19 · 826 阅读 · 0 评论 -
1、架构-服务架构演进史
所谓的“后微服务时代”指的是在微服务架构广泛应用并成熟之后,行业开始探索更进一步的架构模式和技术,以解决微服务在实际应用中遇到的一些挑战,如服务管理的复杂性、数据一致性问题、服务间通信的开销等。在后微服务时代,人们探讨和采纳了一些新的概念和技术,以优化和超越传统微服务架构的限制。原创 2024-05-05 22:43:40 · 964 阅读 · 1 评论