架构目标 高可用性 整体系统可用性最低99.9%，目标99.99%。全年故障时间整个系统不超过500分钟，单个系统故障不超过50分钟。 高可扩展性系统架构简单清晰，应用系统间耦合低，容易水平扩展，业务功能增改方便快捷。 低成本增加服务的重用性，提高开发效率，降低人力成本； 最终一致性 服务设计能满足数据最终一致性，能方便、快捷的满足三方、或者对方对账需求。 质量要求 我们要求在系统设计时候要兼顾下面的各个质量要求 架构总体原则 DID原则解释 Design(D)设计20倍的容量；Implement(I)实施3倍的容量；Deploy（D）...

一.netframework程序迁移到.netcore5.0对于.netframwork程序想要升级为.netcore5.0的方法,微软官方也给出了方法见https://docs.microsoft.com/en-us/dotnet/desktop/winforms/migration/?view=netdesktop-5.0,我这里总结记录一下. 1.首先要检查自己应用程序适不适合迁移.netframework框架和.netcore框架有很大的不同,首先得确保自己当前基于.netframework程序迁移到.netcore上要改变哪些东西。下载迁移分析工具NETPortabilityAna...

工具地址：GitHubdotnet/try-convert：帮助.NET开发人员将他们的项目移植到.NETCore！ 这是一个简单的工具，有助于将.NETFramework项目迁移到.NETCore。 如何使用它 在此处将其作为全局工具安装： dotnettoolinstall-gtry-convert   如果您已经安装了它，请确保更新： dotnettoolupdate-gtry-convert   如果您再次使用该工具，请确保您使用的是最新版本：https://github.com/dotnet/try-convert/releases 如何使用该工...

几年前，我被问到“你是如何变成一名架构师的？”。基于这个话题，我们讨论了很多，比如必要的技术、经验以及所需要的知识储备等。这一次讨论促使我开始思考要成为一名架构师应该具备和学习的东西有哪些，成为一个优秀的架构师应该具备哪些能力和做哪些事情。为此我查阅资料，走访各位大佬，当然也结合自己的经历，最终我输出了今天这样一篇文章，希望通过阅读此文，你可以从此知道自己的架构师之路该怎么走。   什么是架构师？   在开始具体的细节之前，我们先来理清两个定义。 Asoftwarearchitectisasoftwareexpertwhomakeshigh-lev...

一、前言ChatGPT真的产生心智了吗？ 来自斯坦福大学的最新研究结论，一经发出就造成了学术圈的轰动，“原本认为是人类独有的心智理论（TheoryofMind，ToM），已经出现在ChatGPT背后的AI模型上”。所谓心智理论，就是理解他人或自己心理状态的能力，包括同理心、情绪、意图等。这项研究中，作者发现：davinci-002版本的GPT3已经可以解决70%的心智理论任务，相当于7岁儿童。    2023年，面对铺天盖地的AI应用，我们人类终于意识到，有一些东西被永远地改变了。但在这波AI热潮之中，只有一个应用是真正吓人的——ChatGPT。由于...

先抛一下结论：在满足实时性的条件下，不存在两者完全保存一致的方案，只有最终一致性方案。根据网上的众多解决方案，总结出6种，直接看目录：     不好的方案   1、先写MySQL，再写Redis       如图所示：   这是一副时序图，描述请求的先后调用顺序；   橘黄色的线是请求A，黑色的线是请求B；   橘黄色的文字，是MySQL和Redis最终不一致的数据；   数据是从10更新为11；   ...

怎么才能很好地避免低级故障？以下规范在大型互联网公司经过了充分验证，尤其适用于并发量大、数据量大的业务场景。   在设计数据库技术方案时，我们是有自己的设计理念或者原则，还是更多依据直觉去设计？是否曾经懊悔线上发生过的一次低级故障？是否思考过怎样才能避免？设计规范的价值在于提供了一份工作检查清单，我们不断从错误中积累有效经验，指导未来的工作。   以下规范在大型互联网公司经过了充分的验证，尤其适用于并发量大、数据量大的业务场景。安全无小事，很多公司都曾经因为数据泄露导致用户损失惨痛，所以将安全规范放到了第一位。   一、...

一、主从架构 为什么我们要进行读写分离？个人觉得还是业务发展到一定的规模，驱动技术架构的改革，读写分离可以减轻单台服务器的压力，将读请求和写请求分流到不同的服务器，分摊单台服务的负载，提高可用性，提高读请求的性能。 上面这个图是一个基础的Mysql的主从架构，1主1备3从。这种架构是客户端主动做的负载均衡，数据库的连接信息一般是放到客户端的连接层，也就是说由客户端来选择数据库进行读写 上图是一个带proxy的主从架构，客户端只和proxy进行连接，由proxy根据请求类型和上下文决定请求的分发路由。 两种架构方案各有什么特点： 客户端直连架构，由于少了...

天带来的是架构活动中的常见原则，在我们平时做技术方案，非功能设计时一定需要铭记于心这些方法论。 架构目标 高可用性 整体系统可用性最低99.9%，目标99.99%。全年故障时间整个系统不超过500分钟，单个系统故障不超过50分钟。 高可扩展性系统架构简单清晰，应用系统间耦合低，容易水平扩展，业务功能增改方便快捷。 低成本增加服务的重用性，提高开发效率，降低人力成本； 最终一致性 服务设计能满足数据最终一致性，能方便、快捷的满足三方、或者对方对账需求。 质量要求 我们要求在系统设计时候要兼顾下面的各个质量要求 架构总体原则 DID原则解释...

很多同学技术能力很强，架构设计也做得很好，但是在给别人讲解的时候，总感觉像是“茶壶里煮饺子，有货倒不出”。 其实，在为新员工培训系统架构、给领导汇报技术规划、上技术大会做演讲或者向晋升评委介绍工作贡献的时候，如果你能画出一张优秀的 软件系统架构图，就可以大大提升自己的讲解效果，让对方轻松地理解你想表达的关键点。 今天，我就会为你分享软件系统架构图的画图技巧。 4+1视图 说起软件系统架构图，你可能会想到 4+1视图，毕竟很多学习资料上都说它是架构图的标准。那么，到底什么是4+1视图呢？是不是只要按照4+1视图的标准去画，就没有问题呢？ 我们还是从它的由来说起。1995年，...

当谈到架构的高可用时，无论是高可用计算架构，还是高可用存储架构，其本质的设计目的都是为了解决部分服务器故障的场景下，如何保证系统能够继续提供服务。但在一些极端场景下，有可能所有服务器都出现故障。例如，典型的有机房断电、机房火灾、地震、水灾……这些极端情况会导致某个系统所有服务器都故障，或者业务整体瘫痪，而且即使有其他地区的备份，把备份业务系统全部恢复到能够正常提供业务，花费的时间也比较长，可能是半小时，也可能是一天。因为备份系统平时不对外提供服务，可能会存在很多隐藏的问题没有发现。如果业务期望达到即使在此类灾难性故障的情况下，业务也不受影响，或者在几分钟内就能够很快恢复，那么就需要设计异地多...

聊聊从单体到微服务架构服务演化过程 单体分层架构 在Web应用程序发展的早期，大部分工程是将所有的服务端功能模块打包到单个巨石型（Monolith）应用中，譬如很多企业的Java应用程序打包为war包，最终会形成如下的架构： 巨石型应用易于搭建开发环境、易于测试、易于部署；其缺陷也非常明显，无法进行局部改动与部署，编译时间过长，回归测试周期过长，开发效率降低等。集中式架构分为标准的三层：数据访问层、服务层和Web层。 在Web2.0时代刚刚流行的时候，互联网应用与企业级应用并没有本质的区别，集中式架构分为标准的三层：数据访问层、服务层和Web层。 数据访问层用于定义数据访问接口，...

工具地址：GitHubdotnet/try-convert：帮助.NET开发人员将他们的项目移植到.NETCore！ 这是一个简单的工具，有助于将.NETFramework项目迁移到.NETCore。 如何使用它 在此处将其作为全局工具安装： dotnettoolinstall-gtry-convert   如果您已经安装了它，请确保更新： dotnettoolupdate-gtry-convert   如果您再次使用该工具，请确保您使用的是最新版本：https://github.com/dotnet/try-convert/releases 如何使用该工...

具体以电子商务网站为例，展示web应用的架构演变过程。 1.0时代 这个时候是一个web项目里包含了所有的模块，一个数据库里包含了所需要的所有表，这时候网站访问量增加时，首先遇到瓶颈的是应用服务器连接数，比如tomcat连接数不能无限增加，线程数上限受进程内存大小、CPU内核数等因素影响，当线程数到达一定数时候，线程上下文的切换对性能的损耗会越来越严重，响应会变慢，通过增加web应用服务器方式的横向扩展对架构影响最小，这时候架构会变成下面这样： 2.0时代 这时候随着网站访问量继续增加，继续增加应用服务器数量后发现数据库成了瓶颈，而数据库的最主要的瓶颈体现在两方面： 数据库...

一.netframework程序迁移到.netcore5.0对于.netframwork程序想要升级为.netcore5.0的方法,微软官方也给出了方法见https://docs.microsoft.com/en-us/dotnet/desktop/winforms/migration/?view=netdesktop-5.0,我这里总结记录一下. 1.首先要检查自己应用程序适不适合迁移.netframework框架和.netcore框架有很大的不同,首先得确保自己当前基于.netframework程序迁移到.netcore上要改变哪些东西。下载迁移分析工具NETPortabilityAna...

一、引言   在当今数字化时代，零售业正迅速发展，消费者的购物行为和期望发生了巨大的变化。为了满足不断增长的需求，零售企业必须构建高度灵活、稳健可靠的商品系统。   本文将深入探讨零售商品系统的底层逻辑，聚焦领域驱动设计（DDD）和复杂业务系统架构经验，揭示其在零售业务中的应用和价值。   二、面临的挑战   商品系统几乎贯穿了整个业务流程，比如：收银机的扫码加购、下单、商品详情页、小程序加购、营销活动、进销存、供应链、售后、履约等，各个业务环节都以商品为载体。由于商品系统的这种基础性和核心性，它所面临的挑战也愈发显得...

今天我们来谈一谈TDD和BDD两项实践。我们先来说说TDD，也就是测试驱动开发（TestDrvienDevelopment）。 TDD的节奏 或许你已经迫不及待地要举手了：“TDD我知道，就是先写测试，后写代码。”但真的是这样吗？严格地说，“先写测试、后写代码”的做法叫测试先行开发（TestFirstDevelopment），而不是测试驱动开发。 测试驱动开发不也是先写测试后写代码吗？二者之间有什么区别呢？ 要回答这个问题，我们需要知道TDD的一个关键要素， TDD的节奏：红-绿-重构。 红表示写了一个新的测试，测试还没有通过的状态；绿表示写了功能代码，测试通过的状态；而重构...

  一起学习下架构的视角。 架构的视角 在笔者的知识体系中，实际上将架构分为业务架构、应用架构、云基础架构这几大类，业务架构主要着眼于控制业务的复杂性，基础架构着眼于解决分布式系统中存在的一系列问题。无论何种架构，都希望能实现系统的可变的同时保障业务的高可用。 很多时候架构的视角/分类没有明显的边界，通常是交叉的； 有意思的是，软件架构及其视角往往和它所在的部门组织架构有着直接关系。@pdai 业务架构 核心是解决业务带来的系统复杂性，了解客户/业务方的痛点，项目定义，现有环境；梳理高阶需求和非功能性需求，进行问题域划分与领域建模等工作；沟通，方案建议，多次迭代...

架构演进 大型网站的技术挑战主要来自于庞大的用户，高并发的访问和海量的数据，任何简单的业务一旦需要处理数以P计的数据和面对数以亿计的用户，问题就会变得很棘手。大型网站架构主要就是解决这类问题。 架构选型是根据当前业务需要来的，在满足业务需求的前提下，既要有足够的扩展性也不能过度设计，每次的架构升级都是为了解决系统瓶颈而做的。 初始阶段的网站架构 初始阶段都比较简单，通常一台服务器就可以搞定一个网站了，看图。 应用服务和数据服务分离 随着网站业务的发展，一台服务器逐渐不能满足需求；这时候就需要将应用和数据分离，如图。 使用缓存改善网站性能 毫无疑问，现在的网站基本上都会使用缓存，即...

一、数据模型架构规范   1.数据层次的划分   ODS：OperationalDataStore，操作数据层，在结构上其与源系统的增量或者全量数据基本保持一致。它相当于DW数据的一个数据准备区，同时又承担着基础数据的记录以及历史变化。其主要作用是把基础数据引入到DMP。   CDM：CommonDataModel，公共维度模型层，又细分为DWD和DWS。它的主要作用是完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标。 DWD：DataWarehous...