架构2
文章平均质量分 90
架构2
_Rye_
左手代码右手诗
一行代码一行诗
展开
-
77 | 软件工程篇:回顾与总结
软件工程还很年轻,只有 50 年的历史。有关于软件工程的系统与方法论都仍然在快速演化与迭代中。这意味着意我们不必墨守成规。要勇于探索,勇于打破固有的惯例,去建立新的方法论,新的惯例。但需要强调的是,打破惯例不是胡闹,不是要做不尊重科学的 “野蛮人”。今天仍然有那么一批工程师,人数还不在少数,他们随心所欲、任性而为,不喜欢写架构设计文档,不喜欢写单元测试,不喜欢代码互审(code review)。我们首先需要尊重团队协同的科学,在尊重的基础上去探索新的更高效的协同方法论。原创 2023-12-21 17:28:16 · 899 阅读 · 0 评论 -
76 | 软件工程的未来
软件工程项目迭代快速、充满变化、充满不确定性。这使得软件工程成为一门极其独特魅力的科学。今天这门科学仍然还非常年轻,其发展只能以日新月异来形容。软件工程的未来,它的成熟不单单是工程方法论和业务系统软件的成熟,也需要包括人才培养体系的成熟。因为,软件工程的不确定性与它充满设计与创造有关,人的主观能动性是它的优势,但也意味着不确定性无法得到彻底的消除。我们要做的,只能说在大量的不确定性中,找到尽可能多的确定性。原创 2023-12-21 15:04:30 · 793 阅读 · 0 评论 -
75 | 软件版本迭代的规划
今天我们聊的话题是版本迭代的规划。在不同阶段,版本迭代的侧重点会有极大的不同。从 0 到 1 阶段,我们验证的是用户使用姿势,性能并不是第一位的。但是进入扩张阶段,产品竞争力就是关键指标,这时候我们迭代的是用户价值最大的,也是用户真正最在乎的那部分。遇到会对产品产生巨大冲击的需求,头脑别发热,谨慎处理。回到从 0 到 1 阶段的方法论,在少量客户上先做灰度。原创 2023-12-21 09:24:46 · 1073 阅读 · 0 评论 -
74 | 开源、云服务与外包管理
今天我们聊的话题是跨组织的分工与协同。在形态上,我们可以分为:传统外包、开源与云服务。当然还有就是我们今天没有讨论的使用外部商业软件。从形态来说,商业软件很接近传统外包,但是从它的边界来说,因为商业软件往往有明确的业务边界,所以在品质上会远高于外包。当然定制过于严重的商业软件例外,它在某种程度上来说退化为了传统外包。在外包方式的选择上,我们的建议是:我们尽可能不要做太多事情。非核心竞争力相关的,能够外包的我们尽可能外包。在外包选择上,我们优先选择云服务,次选开源,最后才考虑传统的外包。原创 2023-12-20 17:45:53 · 756 阅读 · 0 评论 -
73 | 软件质量管理:单元测试、持续构建与发布
今天我们更加完整地探讨了软件工程的质量管理。整体来说,软件工程与传统工程在质量管理上的理念是迥异的,甚至往往是反其道而行之的。究其原因,还是因为软件工程的核心在于如何在高度的不确定性中找到确定性。原创 2023-12-20 10:08:10 · 1035 阅读 · 0 评论 -
72 | 发布单元与版本管理
今天我们聊的是怎么做版本管理。一个复杂的软件,总可以被分割为若干个独立迭代的发布单元,以便分而治之。发布单元的切割不宜过细,应该以一个小团队负责起来比较舒服为宜,不太小但也不太大。版本的只读设计提高了系统的确定性预期,这是非常非常好的收益。但我们也应注意版本兼容上带来的坑。原创 2023-12-19 18:18:08 · 790 阅读 · 0 评论 -
71 | 如何阅读别人的代码?
对于任何一个项目团队来说,阅读代码的能力都极其重要。哪怕你觉得你的团队共识管理很好,团队很默契,大家的工程习惯也很好,也都很乐意写文档,但这些都替代不了阅读代码这个基础活动。阅读代码是不可或缺的能力。为什么这么说?因为:代码即文档,代码是理解一致性更强的文档。另外,作为一个小补充,我们需要指出的一点是:阅读代码的结果,有时不一定仅仅是架构设计文档的补充与完善。我们有时也会顺手修改几行代码。这是正常现象,而且应该被鼓励。为什么鼓励改代码?是因为我们鼓励随时随地消除臭味。原创 2023-12-19 17:39:54 · 1136 阅读 · 0 评论 -
70 | 怎么写设计文档?
前面在 “45 | 架构:怎么做详细设计?” 我们实际上已经大体介绍了模块级的设计文档怎么写。所以这一讲我们主要较为全面地补充了各类设计文档,包括产品设计、系统的概要设计等在细节上与模块设计文档的异同。原创 2023-12-19 14:18:28 · 836 阅读 · 0 评论 -
69 | 团队的共识管理
这一讲我们谈的是协同的科学。为什么有的团队效率极高,有的团队却进展缓慢,从背后的协同效率来说,共识管理是根因中的根因。共识有非常多的层次。不同层次的共识处于完全不同的维度。它们都极其重要,且相互不可替代。当某个层次的共识出问题的时候,我们需要在相应的层次去解决它。原创 2023-12-19 11:38:23 · 816 阅读 · 0 评论 -
68 | 软件工程的宏观视角
软件工程本身是一个非常新兴、非常复杂的话题。可能需要再花费 50 年这样漫长的时间才能形成更清晰的认知(例如,我们第四章 “服务治理篇” 专门探讨了现代软件工程全过程最后一个环节 “线上服务管理” 这个话题)。作为架构课的一部分,这一章我们将主要精选部分与架构师的工作关系密切的话题来进行讨论,主要包括:团队的共识管理;如何阅读别人的代码;怎么写设计文档;发布单元与版本管理;软件质量管理:单元测试、持续构建与发布;开源、云服务与外包管理;软件版本迭代的规划;软件工程的未来。原创 2023-12-19 10:37:42 · 811 阅读 · 0 评论 -
67 | 架构思维篇:回顾与总结
今天我们对本章内容做了概要的回顾,“架构思维篇” 到此就结束了。理解了本章的内容,对于如何构建一个高度可扩展的软件架构就有了基本的认知。但不要让自己仅仅停留在认知上,需要多多实践。架构的功夫全在平常。无论是在我们架构范式的不断完善上,还是应对架构老化的经验积累上,都是在日常工作过程中见功夫。我们不能指望有一天架构水平会突飞猛进。架构能力提升全靠平常一点一滴地不断反思与打磨得来。在应对架构老化这件事情上,不要轻率地选择进行全局性的重构。要把功夫花在平常,让重构在润物细无声中发生。原创 2023-12-19 09:01:44 · 694 阅读 · 0 评论 -
66 | 架构老化与重构
重构工作是很有技巧性的,很能培养一个人的架构能力。做多了,我们可以建立对代码耦合的条件反射,看一眼就知道架构是否合理。但重构不是技巧性那么简单。实际上从难度来说,重构比一个全新业务的架构过程要难得多。重构,不只是一个架构的合理性问题。它包含了架构合理性的考量,因为我们需要知道未来在哪里,我们迭代方向在哪里。但重构的挑战远不只是这些。原创 2023-12-18 23:06:08 · 1084 阅读 · 0 评论 -
65 | 架构范式:文本处理
文本处理是一个非常庞大的课题,本文详细解剖了我个人在这个领域下的经验总结。相信这些经验对你面对相关场景时会有帮助。但是更重要的一点是,我们平常需要有意识去分析我们工作中遇到的业务场景,从中提炼通用的需求场景形成架构范式的积累。如此,架构的正交分解思想方能得到贯彻。而我们的业务迭代,也就越来越容易。原创 2023-12-18 19:40:27 · 1005 阅读 · 0 评论 -
64 | 不断完善的架构范式
我们在 “56 | 服务治理篇:回顾与总结” 这一讲,也就是第四章结束的时候,谈到我们下一章的内容时提到:我个人不太喜欢常规意义上的 “设计模式”。或者说,我们对设计模式常规的打开方式是有问题的。理解每一个设计模式,都应该放到它想要解决的问题域来看。所以,我个人更喜欢的架构范式更多的是 “设计场景” 的总结。“设计场景” 和设计模式的区别在于它有自己清晰的问题域定义,是一个实实在在的通用子系统。是的,这些 “通用的设计场景”,才是架构师真正的武器库。原创 2023-12-18 17:56:20 · 966 阅读 · 0 评论 -
63 | 接口设计的准则
接口设计是一个老生常谈的话题。接口有分模块的使用界面和模块的环境依赖这两种理解。对于模块的使用界面,我们推崇 KISS 原则,简单自然,符合业务表达的惯例。对于模块的环境依赖,我们遵循的是 “最小依赖原则”,或者叫 “最少知识原则(Least Knowledge Principle,LKP)”,尽可能发现模块中多余的依赖。原创 2023-12-18 17:32:04 · 970 阅读 · 0 评论 -
62 | 重新认识开闭原则 (OCP)
从来没有人这样去谈架构的本质,也没有人这样解读开闭原则(OCP),对吧?其实对于这部 “架构课” 的革命性,我自己从没怀疑过。它的内容是精心设计的,为此我准备了十几年。我们用了四章内容来谈信息科技的需求与架构的演进,然后才进入正题。用写文章的角度来说,这个伏笔的确够深的。当然这不完全是伏笔。如果我们把整个信息科技看作最大的一个业务系统,我们有无数人在为之努力奋进,迭代它的架构。大家在竟合中形成自然的分工。学习信息科技的演进史,是学习架构的必要组成部分。原创 2023-12-18 16:49:51 · 866 阅读 · 0 评论 -
实战:“画图程序” 的整体架构
这一讲我们通过前面实战的画图程序作为例子,来剖析架构设计过程业务是如何被分解的。对于复杂系统,一定要理清核心系统和周边系统的边界,让整个程序的内核最小化。另外,我们也实际分析了画图程序中,周边模块对核心系统的伤害值。这个数据可以很好地评判不同架构方案的好坏。如果你自己也实现了一个 “画图程序”,可以根据这几讲的内容,对比一下我们给出的样例代码,和自己写的有哪些架构思想上的不同,这些不同之处的得失是什么?原创 2023-12-18 15:24:41 · 857 阅读 · 0 评论 -
61 | 全局性功能的架构设计
架构分解中有两大难题。其一,需求的交织。不同需求混杂在一起,也就是我们今天说的全局性功能。其二,需求的易变。不同客户,不同场景下需求看起来很不一样,场景呈发散趋势。但无论如何,我们需要坚持作为一名架构师的信仰:任何功能都是可以正交分解的,即使我目前还没有找到方法。原创 2023-12-18 14:08:51 · 913 阅读 · 0 评论 -
60 | 架构分解:边界,不断重新审视边界
这一讲我们通过一个实际的例子,来剖析架构设计过程中我们如何在思考模块边界。最重要的,当然是职责。不同的业务模块,分别做什么,它们之间通过什么样的方式耦合在一起。这种耦合方式的需求适应性如何,开发人员实现上的心智负担如何,是我们决策的影响因素。为了避免留下难以调整的架构缺陷,我们强烈建议你认真细致做好需求分析,并且在架构设计时,认真细致地过一遍所有的用户故事(User Story),以确认我们的架构适应性。原创 2023-12-18 11:46:30 · 780 阅读 · 0 评论 -
59 | 少谈点框架,多谈点业务
今天谈的内容,核心指向一点:架构就是业务的正交分解。每个模块都有它自己的业务。这里我们说的模块是一种泛指,它包括:函数、类、接口、包、子系统、网络服务程序、桌面程序等等。它看似简单,但是它太重要了,重要到需要单独一讲来把它谈清楚。它是一切架构动作的基础。架构行为的三步曲:“需求分析”、“概要设计”、模块的 “详细设计”,背后都直指业务的正交分解,只是逐步递进,一步步从模糊到越来越强的确定性,直至最终形成业务设计的完整的、精确无歧义的解决方案。原创 2023-12-18 10:32:29 · 808 阅读 · 0 评论 -
58 | 如何判断架构设计的优劣?
今天我们探讨的话题是如何评判架构设计的优劣。首先我们谈的是架构设计的基本准则,它们虽然不足以明确说谁好或是不好,但是指明了方向。然后我们开始对架构好坏做定性甚至定量的分析。考虑到核心系统的重要性,我们单独引入了一个伤害值来评估它的纯洁度。最后,我们对模块自身的接口或实现,给出了耦合度测量公式。通过这个公式,我们明确了我们架构设计的价值主张。但我们需要意识到的一点是,这些并不是全部。判断模块间的耦合度是复杂的。上面我们的公式某种程度上来说只考虑了静态依赖关系,而没有考虑动态依赖。原创 2023-12-18 09:19:28 · 878 阅读 · 0 评论 -
57 | 心性:架构师的修炼之道
架构师成长之旅,是心性修炼之旅。我们需要记得,并不是理解了架构思维的原则,就能够做好架构。架构之道,是虚实结合之道。理论与实践相结合。从实悟虚,从虚就实,运用得当方得升华。架构思维的感悟并不能一步到位,永远有进步的空间,需要我们在不断实践中感悟,升华自己的认知。从技能来说,我们可能把架构师能力去归结为:理需求的能力;读代码的能力;抽象系统的能力。但是架构师修炼之道,更难的是在心性上,这包括:同理心的修炼,认同他人的能力。全局观的修炼,保持好奇心和学习的韧性。原创 2023-12-17 23:14:33 · 825 阅读 · 0 评论 -
56 | 服务治理篇:回顾与总结
今天我们对本章内容做了概要的回顾,到此为止,我们 “基础平台”、“桌面开发”、“服务端开发”、“服务治理” 这四大模块就结束了。从工程师架构设计角度来说,它们基本上涵盖了我们会打交道的绝大部分通用业务场景。理解了这几章的内容,整个软件大厦的骨架就可以明了了。下一步应该学什么?架构思维原则?或者是设计模式?架构思维的确是有很多共性的东西,值得我们总结出来细细体会。比如 “开闭原则”,多么有力的架构思维的总结,值得我们时时拿出来提醒自己。不过,我个人不太喜欢常规意义上的 “设计模式”。原创 2023-12-17 20:24:23 · 918 阅读 · 0 评论 -
55 | 云计算、容器革命与服务端的未来
今天我们聊的话题是服务端的未来。云计算和容器革命将服务端的基础设施化推向了高潮。未来,也许我们并不需要专门的服务端开发工程师来做业务开发。原创 2023-12-17 19:42:26 · 1073 阅读 · 0 评论 -
54 | 业务的可支持性与持续运营
今天我们聊的主要是一个视野的问题。除了产品的功能外,实际上为了产品能够更好地服务好客户,我们需要关注售前、售后支持能力的构建。为了更好地支持客户,以及进行后续用户体验的改善,我们往往需要将用户行为记录写到日志系统中,以便于进一步地分析和挖掘。原创 2023-12-17 19:29:05 · 837 阅读 · 0 评论 -
53 | 过载保护与容量规划
总结下我们今天的内容。我们聊的话题主要是关于过载。所谓过载,最直白的理解,当然就是因为活跃的用户超过了资源的承载能力范围,导致某类资源耗尽,进而体现出系统过载。当一个系统过载时,某些东西总是要被牺牲掉。一旦一个服务越过了临界点,服务一些用户可见错误,或者低质量结果,要比尝试继续服务所有请求要好。理解这些临界点所在,以及超过临界点系统的行为模式,是所有想避免因过载而引发雪崩效应的 SRE 所必需具备的。如果不加小心,某些原本为了降低服务背景错误率或者优化稳定状态的改变,反而会让服务更容易出现事故。原创 2023-12-17 19:23:11 · 804 阅读 · 0 评论 -
52 | 故障排查与根因分析
今天我们聊的是线上故障的排查与根因分析。从理论上讲,我们将故障排查过程定义为反复采用“假设 - 验证排除”手段的过程:针对某系统的一些观察结果和对该系统运行机制的理论认知,我们不断提出一个造成系统问题的假设,进而针对这些假设进行测试和排除。为了有效排查故障,日志系统在里面起到了关键作用。定位问题本身就是 “假设 - 验证排除 - 再假设 - 再验证排除” 这样的循环,直至最后定位到问题。所以基于时序数据的日志系统,往往查询支持非常多样化的过滤条件,功能非常强大。原创 2023-12-17 19:18:48 · 835 阅读 · 0 评论 -
51 | 故障域与故障预案
今天我们就聊聊故障产生的原因与对策。可以导致故障的因素非常多,我们大体分为以下几种。软硬件升级与各类配置变更,即发布。软硬件环境的故障。终端用户的请求。今天我们重点讨论的是 “软硬件环境的故障” 引发的服务异常及其故障预案。我们追求的是 24 小时不间断服务,所以站在更长的时间维度,或者更大的集群规模维度看,可以预期软硬件环境的故障是一种必然。原创 2023-12-17 19:09:30 · 869 阅读 · 0 评论 -
怎么保障发布的效率与质量?
今天我们探讨 “发布与升级” 的实践,如何既保证质量,又能够兼顾效率。正确的做法当然不是为了快而去忽略流程,而是在不断的发布经历中总结经验教训,把每个环节干得更快更有效率。原创 2023-12-17 19:05:00 · 756 阅读 · 0 评论 -
50 | 日志、监控与报警
监控与报警是一项非常复杂的事务,这种难度不是因为业务流程复杂导致的,而是因为与业务的高耦合导致。监控系统需要跟随不断演变的软件一起变化。软件的全局或某个局部发生重构,负载特性和性能目标就会变化。某个不常见的、自动化比较困难的报警,很可能随着用户增长很快变成一个经常触发、需要一个临时的脚本来应对的问题。这时,就需要有人去寻找和消除背后的根源问题,而不是在持续被故障牵着鼻子走。解决故障的方案有可能是需要进行业务的架构调整。这也是监控与报警的复杂性所在:你需要和业务开发工程师一起配合去完善系统。原创 2023-12-17 19:00:40 · 880 阅读 · 0 评论 -
49 | 发布、升级与版本管理
今天我们探讨服务治理的第一个环节:发布与升级。它包括了以下这些子过程:构建;测试;打包;部署;配置变更。我们并没有探讨具体的发布与升级系统怎么做,虽然业界针对发布的各个环节其实都有蛮多的实作案例。如果你正在评估应该采纳什么样的系统,可以结合我们今天探讨的发布哲学来进行评估。发布系统非常复杂,有很大的事务工作量。要做到高效的发布能力,工程师思维是关键性的支撑,我们需要坚持以系统化的思维来彻底解决发布问题。原创 2023-12-17 18:58:45 · 838 阅读 · 0 评论 -
48 | 事务与工程:什么是工程师思维?
今天看起来我们的话题有了一次比较大的跳跃,谈起了工程师思维和工程师文化。但服务治理不是纯理论,没有简洁的抽象问题模型。我们面对的是现实世界的复杂性。这些现实的复杂性,背后是大量的事务工作,尤其是我们对问题还不够了解的时候。这个时候,工程师思维在背后起到了关键性的支撑。正是我们坚持了批判精神,坚持了以系统化的思维来把问题彻底解决,才有今天服务治理系统的日新月异的发展。原创 2023-12-17 18:56:14 · 905 阅读 · 0 评论 -
47 | 服务治理的宏观视角
今天我们对本章服务治理篇做了概要的介绍。服务治理不是纯理论,没有简洁的抽象问题模型,我们面对的是现实世界的复杂性。这些现实的复杂性,必然带来解决方案的复杂性。直到今天为止,很多问题仍然没有被圆满解决。但是,它们的确已经在被解决的边缘。相关领域的探索与发展,日新月异。原创 2023-12-17 18:32:57 · 771 阅读 · 0 评论 -
46 | 服务端开发篇:回顾与总结
到今天为止,我们第三章 “服务端开发篇” 就要结束了。今天,让我们对整章的内容做一个回顾与总结。本章我们主要涉及的内容如下。服务端开发这个分工,出现的历史极短。如果我们从互联网诞生算起也就 40 多年的历史。以进入民用市场为标志,它真正活跃的时段,其实只有 20 多年。作为架构师,记住这一点非常非常重要。20 多年能够形成的有效经验并不多。这意味着我们不能固步自封,很多惯例是可以被挑战的,并且最终也必然被挑战的。作为最底层的服务端操作系统,最初从桌面操作系统而来。原创 2023-12-17 14:41:43 · 951 阅读 · 0 评论 -
45 | 架构:怎么做详细设计?
今天我们聊的是怎么做详细设计。详细设计并不是只谈实现就完事,更不是一个架构图。它包括以下这些内容。现状与需求现在在哪里,遇到了什么问题,要作何改进。原创 2023-12-16 18:11:52 · 931 阅读 · 0 评论 -
44 | 实战(四):“画图”程序后端实战
总结一下今天的内容。今天我们主要讨论如何基于 OAuth 2.0 来改造 QPaint 的帐号与授权机制。实际上这方面业界有非常成熟的实践,所以我们没有太大的必要去自己重新造一个轮子。我们的核心思路是,基于协议来提供帐号系统,基于OAuth 2.0协议来实现 Open API 体系。我们不只是用标准的协议,背后的实现也基于开源项目:CoreOS 团队开发的 dex。这样,我们就可以把关注的重心放在 QPaint 业务本身上。原创 2023-12-15 23:18:32 · 871 阅读 · 0 评论 -
43 | 实战(三):“画图”程序后端实战
今天我们主要聊了帐号与授权相关的基础体系,重点介绍 OAuth 2.0 背后的逻辑。下一讲我们会讨论如何基于 OAuth 来完成 QPaint 的帐号与授权机制。原创 2023-12-15 19:15:20 · 809 阅读 · 0 评论 -
42 | 实战(二):“画图”程序后端实战
总结一下今天的内容。今天我们主要改造的是底层的业务逻辑实现层。一方面,我们对使用界面(接口)作了多租户的改造。多租户改造从网络协议角度来说,主要是增加授权(Authorization)。从底层的 DOM 接口角度来说,主要是 Document 类增加 uid 参数。另一方面,我们基于 mongodb 完成了新的实现。我们对数据结构和算法作了详细的描述。原创 2023-12-15 18:34:16 · 781 阅读 · 0 评论 -
41 | 实战(一):“画图”程序后端实战
我们总结一下今天的内容。从今天开始我们会一步步将之前写的 mock 服务端改造为真实的服务端程序。我们第一步改造的是 RPC 框架和单元测试。这样我们第一次开始依赖第三方的代码库,如下:http://github.com/qiniu/http (用到 restrpc)http://github.com/qiniu/x (用到 mockhttp)一旦有了外部依赖,我们就需要考虑依赖库的版本管理。好的一点是大多数现代语言都有很好的版本管理规范,对于 Go 语言我们用 go mod 来做版本管理。原创 2023-12-15 17:41:58 · 833 阅读 · 0 评论 -
40 | 服务端的业务架构建议
我们总结一下今天的内容。服务端业务架构,主要是怎么做一个多租户的 Model 层。Model 层本身最重要的是自然体现业务逻辑,它和具体的行业的领域问题相关,对此我们无法进一步展开。但服务端程序还是有它很鲜明的特点。今天我们重点讨论了服务端业务架构相关的通用问题。包括:网络协议、授权、RPC 框架、单元测试等等。当然其实还有一个问题,就是选什么样的存储中间件。它和具体的业务特征更为相关,这一点在后面我们实战案例中再做探讨。我们服务端开发相关的内容就暂时告一段落,下一讲开始我们进入实战。原创 2023-12-15 17:34:24 · 850 阅读 · 0 评论