这是学习笔记的第 2069 篇文章 前几天碰到了一个严重的硬件问题导致服务受到影响，我在总结思考的时候，脑袋里冒出了一个观点:过度设计。...，如果节点漂移之后，某一个服务器的资源负载会有显著的提升，而在批量计算的过程中一旦因为资源的过度使用而导致集群节点再次出现问题，那么这种问题就是连锁式的，排除这种极端情况，一个服务器上部署了过多的节点，...我想了下我们工作中存在很多的过度设计问题，如果细数一下这个过程，可以从功能，性能，可用性这个阶段来说，而归根结底是基于成本，即最小的成本获得最高的收益，这个收益绝非是简单的性能。...，而过度倾斜就会是上面的这种情况，这种情况下是基于性能的视角来设计的，但是没有充分考虑数据的可用性和可恢复性，所以第三层的设计应该是基于故障的设计方案，我们在设计之初就应该明确服务器是不可靠的，资源是不能完全可靠的...常见的过度设计有 1.集群规模过大，但是使用率不高 2.单机多实例设计过度，导致业务难以恢复 3.数据分片过度 ?
软件开发的哪个阶段最容易招人喷？如果你严格按照什么瀑布模式、敏捷模式开发的话，你会发现永远是概要设计的评审阶段。 这个时候，屎山还没有成为既定的事实。...这也是操蛋的DDD所追求和说明的，把一个简单的数据库操作给拆的七零八落。 如果把这种设计哲学推广开来的话，你会发现几乎每个地方都有问题。 项目中使用了Kafka，如果将来换成Pulsar呢？...值得注意的是，Spring家族在这些完美的目标上，产出了不少优秀的组件，比如Spring Data、Spring Cloud Stream等。 但这不代表你可以过度设计。...在开发中，你为什么不想着为开发语言的耦合创造一个第三方语言呢？这个成本是大的，而且是非常没有必要的，如果真的有这种需求，你可以把它放在重构上。 同样的话，我也可以送给纠结底层数据库存储的同学。...内部技术和外部协作 我觉得冲突产生的根本原因，是评审者甚至开发者，没有弄清项目的边界是什么。
原文链接：https://mp.weixin.qq.com/s/o-P9EUMPbAZlTwbykBioPQ 提到过度设计，大概很多人都知道。但怎么样界定过度设计，确是很难说的清楚。...在做抽象的时候，或者在利用一些设计模式的时候（其实这也是一种抽象，只不过是利用前人总结好的抽象）。目的是为了什么？ 在我的上一篇文章中 《系统架构设计的一点思考》提到了系统复杂度的概念与描述。...很多人之所以会有着喜欢用设计模式，有一个思维是在于，我手中有一把锤子，看见什么都想去锤下。这种的是在于，从自身主观思维出发，只看到局部，而未见整体的系统结构。...评判的标准界定，我认为是应该是从系统的角度，去做评判才是正确的。这个评判不是以个人主观意识出发的。而是这个系统，在用了某个抽象之后。...目前我所能了解到的一些方向： 1、petril网络 Petri网是Carl Adam Petri于1962年在博士论文中首次提出来的。
依我看，过度设计要比缺乏良好的开发实践扼杀更多的产品。 在讨论详细情况之前，让我来介绍一下我的背景。当上产品经理之前，我是个工程师。实际上，我受过计算机科学的正规训练。...尽管在我的职业生涯中，我总是更接近业务，而不是自己编写代码，但我创建、扩展并管理了工程和产品团队，而且规模相当。 所以，我并不是从外表来谈论过度设计的问题。...嗯，请坐稳椅子，因为在经历了二十年的职业生涯之后，我可以向你保证，过度设计并非例外：这是常态。 过度设计的原因 谁也不是出于恶意这么做的。...假如一个工程师没有激动人心的挑战要面对，他很可能只是尝试了一些新事物，最终使问题复杂化。 过度设计的后果 在文章一开始，我就提到过度设计将扼杀初创公司，我并不是在开玩笑。...他们的回答会帮助你辨别这是否是一种过度设计的情况。 最后，更多的是面向创始人，优先聘用已经在产品公司有一定经验的高级工程师。寻找“战争创伤”的面试。询问他们最痛苦的经历以及他们是如何应对的。
在计算机行业最早是谁使用我就不知道了，但最有名的应该是1975年 Fred Brooks的《人月神话》里“自律—第二系统效应”一节提到的overdesign： ? ?...---- 即使是看起来真的是说“内部”的设计的，其实有可能还是需求问题，比如，网络上摘的一篇名为《软件开发-什么是过度设计》的文章里举的例子： ?...以上文章以为所说问题是“设计”，其实问题是，考虑了不存在的需求，跟设计过度不过度没什么关系。...至于真正的“过度设计”——系统的需求是正确的，但系统内部构造精妙到过分了，呵呵，似乎我见都没见过。 见到的基本上都是伪装成“过度设计”的“没有设计”。...更糟糕的是，“过度设计”还成为拒绝思考的遮羞布——我害怕自己“过度设计”，所以干脆就不学习设计了，这样就避免了陷入“过度设计”的陷阱。
这些数据通常很少会进行修改，所以也不担心一致性的问题。 2）字段冗余 一种典型的反范式设计，利用空间换时间，为了性能而避免join查询。...但这种方法适用场景也有限，比较适用于依赖字段比较少的情况。而冗余字段的数据一致性也较难保证，就像上面订单表的例子，买家修改了userName后，是否需要在历史订单中同步更新呢？...因此需要单独设计全局主键，以避免跨库主键重复问题。...5 数据迁移、扩容问题 当业务高速发展，面临性能和存储的瓶颈时，才会考虑分片设计，此时就不可避免的需要考虑历史数据迁移的问题。...不到万不得已不用轻易使用分库分表这个大招，避免"过度设计"和"过早优化"。分库分表之前，不要为分而分，先尽力去做力所能及的事情，例如：升级硬件、升级网络、读写分离、索引优化等等。
在软件开发领域，不陷入过度工程化的陷阱，写出可维护的代码的做法，已经越来越少见了。...让我们探索哪些流行的成分可能对中型应用有益，并评估它们是否会帮助你管理复杂性，或者是否会制造出比解决的问题更多的问题。 Typescript YES ✅ 首先，我们来解决这个问题。...Hexagonal Architecture 六边形架构 NO ⛔️ 六边形架构，也被称为端口和适配器，是另一种旨在在应用程序的核心业务逻辑和其外部依赖（如数据库、API和用户界面）之间创建清晰分离的架构模式...这种分离允许更大的灵活性、可测试性和可维护性。 与DDD类似，实施六边形架构对于具有复杂业务逻辑和众多外部依赖的大型应用程序可能是有益的，但对于中型应用程序来说，这绝对是过度设计。...总结 过度工程化是所有恶的根源。当涉及到中等规模的应用开发时，我们大多数人都有罪。
一、问题引入 学过数据库的同学都知道外键，外键能够保证数据的一致性。...不过人家书的作者技术肯定比我高多了，既然这样说，肯定有他的道理。每当我听到一个观点时，我都不会急着去反驳否定它，我喜欢自己私底下先搞清楚来，这样才有发言权。 二、建还是不建？...优点： （1）实现表与关联表之间的数据一致性； （2）可以迅速的建立一个可靠性非常高的数据库结构，而不用让应用程序层去做过多的检查； （3）可以提高系统鲁棒性、健壮性； （4）可以实现开发人员和数据库设计人员的分工...； （4）外键还会因为需要请求对其他表内部加锁而容易出现死锁情况； （5）容易出现数据库I/O的瓶颈； 2、不建，有啥好建的 说实现，现在我做项目都不用外键了。...优点： （1）减少了数据库表与表之间各种关联的复杂性； （2）牺牲应用服务器资源，换取数据库服务器的性能； （3）将主动权把控在自己手里； （4）去掉外键相当于优化数据库性能； 缺点： （1）所有外键的约束
可能，习惯了关系型数据库的你没觉出什么来，下面看一下非关系型数据库的设计思路。...是不是比关系型数据库的设计思路更加灵活清晰？！ 好了，对于关系型数据库和非关系型数据库的讨论就不再深入了，没有好坏之分，各有优势。...项目中的Mongodb设计 NodeJS的流行，离不开丰富的中间件支持，对于操作Mongoose的中间件，我推荐“mongoosejs”， 官网称之为：“Mongoose ODM”。...Mongoose内部实现了一套验证机制及灵活的数据库操作，也是我推荐的一大理由。...，在进行数据库设计，就容易很多了。
越是简单的东西，越是容易被忽略，我来带你们好复习一下！ ?...简单工厂模式的UML ? 代码实现 别诟病我这中文写代码，问就是不是做项目，这样更容易知道自己写的啥！...{ @Override public void Method() { System.out.println("我是第一种产品，这是我的功能"); } } package 简单工厂模式;...写在最后： 我叫风骨散人，名字的意思是我多想可以不低头的自由生活，可现实却不是这样。...你的点赞、收藏、关注是对我最大的鼓励！
我说的很多内容（SAP技术内容除外），并不是特定对于SAP来讲，而是很多行业基本都是这样，针对一个行业概括起来，就是大部分行业的规则。 对于SAP行业的待遇问题，我觉得还是有必要多说几句。...如果非要让我给个建议，那么，可以去看一下learninghub，其他的机构我就不多说了，要是有朋友有这方面经验的，可以留言或者后台发消息给我。 有朋友带着或者通过自学。...在这里多提一点就是cloud，如果你关注了我的公众号（SAP Technical），会发现我推送的关于SAP Cloud的文章及未来发展。...image.png 是否适合SAP行业 这个话题，我的理解是没有严格的什么界限，只要你觉得合适，那就是合适，没有人会对你说不合适。以下几点基本上涵盖了是否适合SAP行业。 是否感兴趣。...很少有人能为了理想活一生，我们平凡人大多数都是为了更好的生活而活一生。所以，面对现实生活，你是否觉得做SAP行业可以让你的生活更好，或者做SAP根本养不活家人。
起初，利用简单的设计模式，如经典的单例模式，工厂模式等23设计模式，来进行程序设计，这时，只是简单的接受前人总结的模式。缺点，模式有限。...仔细思考，其实发现，这23种设计模式，全部能够对应到现实生活。就如最简单的工厂模式，这个和现实生活中的是一样的。 是否可以摆脱23设计模式的限制？...是否可以转变思想，先模拟现实模式，再来程序设计？ 答案是肯定的。将需求转变成现实模式，真正实现程序是对现实生活的模拟，然后再来实现程序。 这里的设计，包括程序设计，架构设计。...那么我个人的思考形成过程。 从简单的行为，到群体的行为关注。 有简单的种群行为分析，如生物种群模型，利用微分方程来建模。...从这段话来体现，IT系统以后越来越复杂，是否也是可以通过构建简单的个体模块，通过一系列的，激励与惩罚，实现系统的自足自，让其涌现出系统智能？ 我个人认为，系统的演进，应该是殊途同归的。
逸言 | 逸派胡言 我结合领域驱动设计、事件风暴、DCI模式等方法提出的通过领域场景来驱动设计的一种简明设计方法。...我并非要刻意创造一个方法体系，仅仅是在领域驱动设计的大旗下，发现以“场景”为起点，会有更为系统的设计过程。设计本身会有许多驱动力，场景驱动的方式并没有超出领域驱动的范畴，只是以场景来描述会更准确。...分解任务其实最符合设计者思维方式，这其实是一种自顶向下的设计方式，它同时也作为测试驱动开发的前置条件。我根据子任务的粒度，将这些任务分为“组合任务”和“原子任务”。...任务的类别划分直接影响到后面的职责分配。 分配职责的基础是角色构造型。下图是我总结的主要角色构造型： ? 在场景驱动设计中，发挥重要的角色构造型包括：应用服务、领域服务、聚合和网关。...可以看出，分解任务是场景驱动设计中的关键。只要任务分解合理了，按照我固化的设计流程进行职责分配是水到渠成的过程。我们还可以借助一些工具来显化职责分配与对象协作。
Linux 多年来取得的成绩毋庸多言。但最近，reddit 上有人发起了一个话题，想知道 Linux 的内核设计是否已经过时，并得到了一些有趣的答案。...这位 Ronis_BR 的用户提问大致如下： Linux 是在 1992 年启动的，一些特性到现在都没有改变。我猜想最新的操作系统内核设计技术（如果存在…）应该较之前有很大的进步。...那 Linux 内核是否已经过时？ 与 Windows、macOS、FreeBSD 内核的设计相比，Linux 内核的设计有没有在哪些方面比较先进？（注意，重点是设计的先进，而不是哪一个更好）。...Linux kernel 对现代内核的设计其实是非常了解的，只是它选择了保持传统的形式。 内核设计的核心在于“安全/稳定”和“性能”之间的关系。...比如，理论上微内核也有一些非常好的设计选择，使得它们具有便携性、可靠性和潜在的自我修正能力。 然而，无论理论多么好，人们总是会根据实际情况进行设计。
我将从下面的方向来对我所理解的接口设计做个总结： 接口参数定义 -> 接口版本化的问题 -> 接口的安全性 -> 接口的代码设计 -> 接口的可读性 -> 接口文档 -> 我遇到的坑 接口参数定义 接口设计中往可以抽象出一些新的公共参数...曾经也去调研了很多关于接口版本化的资料和设计，最后我得到的结论大致如下： 接口的版本区分为： 大版本 原则：大版本的数量最多控制到5个以内(我个人跟倾向于3个)，超过版本限制的版本提示升级到新版本 方案...v=1.1 接口的安全性 接口的设计肯定绕不开安全这两个字，为了达到尽可能的安全，我们需要尽可能的增加被攻击的难度，以下是我了解和使用到的一些常见的手段去增加接口的安全性(https这里就不讨论了)：...-> 解耦业务 即插即用 这个过程的关键字：抽象成类 前置中间件 注入 接着就是我们代码设计的层面了，如何抽象公共的部分与业务代码解耦。...关于接口设计可读性的我的一些思考： url 非RESTFUL: 资源／资源／操作(动词)， 例如 content/article/get -> 获取内容资源下的一篇文章资源 RESTFUL: 资源／资源
我将从下面的方向来对我所理解的接口设计做个总结： 接口参数定义 -> 接口版本化的问题 -> 接口的安全性 -> 接口的代码设计 -> 接口的可读性 -> 接口文档 -> 我遇到的坑 接口参数定义 接口设计中往可以抽象出一些新的公共参数...曾经也去调研了很多关于接口版本化的资料和设计，最后我得到的结论大致如下： ?...接口的安全性 接口的设计肯定绕不开安全这两个字，为了达到尽可能的安全，我们需要尽可能的增加被攻击的难度，以下是我了解和使用到的一些常见的手段去增加接口的安全性(https这里就不讨论了)： 过期验证／签名验证...接口的代码设计 -> 解耦业务 即插即用 这个过程的关键字：抽象成类 前置中间件 注入 接着就是我们代码设计的层面了，如何抽象公共的部分与业务代码解耦。...关于接口设计可读性的我的一些思考： ? ? 接口文档 好的接口文档就是生产力， swagger + api blueprint 自行google吧?
在数据库设计时，主要就是对实体和关系的设计，实体表现出来就是表，关系表现出来就是外键。而对于一个表，由两部分组成：主键和属性。主键的简单定义就是表中为每一行数据的唯一标识。...由于主键常常用于检索数据，也用于表之间的关联，所以主键的设计的好坏将会严重影响数据操作的性能。下面来介绍下主键设计的几个考虑因素。...数据库主键与业务主键 前面说到一个表可能有很多个唯一标识的候选键，那么这么多候选键中，哪个应该拿来做主键呢？...前面已经说到主键应该越短越好，而且是建议是一个没有意义的自增列，那么是不是就不会再需要联合主键呢？答案是否定的，我们仍然可能会使用到联合主键。...，但是由于我们大部分情况下都是使用主键检索数据，所以大部分数据库的默认实现，在建立主键时会自动建立对应的索引。
好的数据库设计工具，可以帮助我们进行思考并提高我们的设计效率。以前一直使用的是PowerDesigner，最近发现Navicat的数据库设计功能也很不错，界面简洁且容易使用，特此推荐给大家。...Navicat Navicat是一套快速、可靠的数据库管理工具，专为简化数据库的管理及降低系统管理成本而设。它的设计符合数据库管理员、开发人员及中小企业的需要。...首先我们需要一份有外键关系的SQL文件，这里我已经生成好了，下载地址：https://github.com/macrozheng/mall-learning/blob/master/document/navicat...之后选择需要导入的数据库pd-test； ? 导入成功后就可以看到完整、有关系的数据库设计图了，大家可以按自己的喜好修改表的位置。 ?...总结 总的来说Navicat的数据库设计功能还是相当不错的，简洁易用，界面也很漂亮。设计数据库在PowerDesigner中只是一个功能，使用起来未免太沉重，而Navicat的数据库设计功能更轻巧！
大家好，又见面了，我是你们的朋友全栈君。...1、设计一个合适的关系数据库系统的关键是关系数据库模式的设计，即应构造几个关系模式， 每个模式有哪些属性，怎样将这些相互关联的关系模式组建成一个适合的关系模型，关系数据库 的设计必须在关系数据库设计理论的指导下进行...2、关系数据库设计理论有三个方面的内容：函数依赖、范式和模式设计。函数依赖起核心作用， 它是模式分解和模式设计的基础，范式是模式分解的标准。...说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的设计基本要求，一般设计中都必须满足第一范式（1NF）。不过有些关系模型中突破了1NF的限制，这种称为非1NF的关系模型。...换句话说，是否必须满足1NF的最低要求，主要依赖于所使用的关系模型。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
腾讯会议
云直播
对象存储
