架构设计

https://blog.csdn.net/hu948162999/article/details/78861860； https://blog.csdn.net/g6U8W7p06dCO99fQ3/article/details/82321193； https://blog.csdn.net/bestxianfeng163/article/details/82143613； 来源： https://www.cnblogs.com/applelife/p/11588462.html

缓存使用场景   缓存是提高应用程序性能的最常见的一种技术，常适用于读多写少的场景。按照架构层次可以分为：客户端缓存、页面缓存、应用缓存、持久层缓存。   其中应用缓存设计最为复杂，本文主要讨论应用缓存的设计。 更新or淘汰   缓存的存储一般为键值对的方式，存储的值可能为对象或集合或单值，比如用户信息、购物车列表、阅读计数等。而缓存发生变化时的更新则存在两种策略：更新or淘汰。一般来说淘汰最为简单。   淘汰数据可以简单的将缓存删除，更新数据则需要将新的值放入缓存中；淘汰数据会导致查找缓存时的一次miss，而更新缓存则不存在此问题，特别时某些复杂场景下淘汰缓存可能会导致缓存穿透。   如果更新缓存不需要增加额外的复杂计算或者分支流程推荐使用更新缓存的策略。另外如果对主线流程的响应速度要求比较高可以采用异步方式更新缓存。 缓存对象or单值数据   一般倾向于缓存单值数据而非对象，当然不包含其它业务对象的数据可视为单值数据（可以存储为string）。例如redis，支持List、Hash、Set（ZSet）和String，对于其中的集合对象可以根据不同的业务场景选用。   存储一个复杂对象需要将对象的属性拆分成不同的key-value来存储，比如： Book{ string id; int buyCount; string name; }。 可以拆分成： Book.ID

缓存使用场景   缓存是提高应用程序性能的最常见的一种技术，常适用于读多写少的场景。按照架构层次可以分为：客户端缓存、页面缓存、应用缓存、持久层缓存。   其中应用缓存设计最为复杂，本文主要讨论应用缓存的设计。 更新or淘汰   缓存的存储一般为键值对的方式，存储的值可能为对象或集合或单值，比如用户信息、购物车列表、阅读计数等。而缓存发生变化时的更新则存在两种策略：更新or淘汰。一般来说淘汰最为简单。   淘汰数据可以简单的将缓存删除，更新数据则需要将新的值放入缓存中；淘汰数据会导致查找缓存时的一次miss，而更新缓存则不存在此问题，特别时某些复杂场景下淘汰缓存可能会导致缓存穿透。   如果更新缓存不需要增加额外的复杂计算或者分支流程推荐使用更新缓存的策略。另外如果对主线流程的响应速度要求比较高可以采用异步方式更新缓存。 缓存对象or单值数据   一般倾向于缓存单值数据而非对象，当然不包含其它业务对象的数据可视为单值数据（可以存储为string）。例如redis，支持List、Hash、Set（ZSet）和String，对于其中的集合对象可以根据不同的业务场景选用。   存储一个复杂对象需要将对象的属性拆分成不同的key-value来存储，比如： Book{ string id; int buyCount; string name; }。 可以拆分成： Book.ID

本文是阅读<LinkeddIn: A Professional Social Network Built with JavaTM Technologies and Agile Practices>后的一些总结思考。 简介 LinkedIn创建于2003年，拥有（指发布那个PPT时的统计数字）： 两千两百万注册会员 每月四百万UV（Unique Visitor） 每天四千万PV（Page View） 每天两百万次搜索 每天25万次邀请 每天一百万个答案被发布 工作流程 持续集成、持续发布，每个版本的开发周期控制在2-4周，使用了Hudson结合SVN 所有任务都被分割成小的可控的工程卡片，LinkedIn内部开发了一个系统支持这种工程卡片，有点类似敏捷开发中的CRC卡片 注重测试：单元测试和集成测试，除了使用单元测试和集成测试工具外，还使用EasyMock来避免频繁集成测试耗时太长的缺点 尽量避免会议，站立式会议 整体架构演化 2003年-2005年的架构如下： 特点： 结构简单，核心数据库只有一个 GUI层、业务逻辑层（BL Layer）和服务层（Services Layer）都放在同一个Web服务器上 2006年的架构如下： 特点： 相比之前搜索模块被单独提出来 最大的变化是数据访问层，增加了Databus这种分布式总线式数据处理管道，并且增加了多个从库（只用于读

看完“实现模型”，你是否长吁一声，准备拿起咖啡，惬意的喝上一杯？毕竟我们已经完成了从用例到编码的全过程了，确实是值得庆祝的一件事情，但“革命尚未成功、同志还需努力”，现在还不是享受的时候，接下来我们需要进入“处理模型”阶段。 l “处理模型”阶段的任务 “处理模型”英文是“Process Model”，Process在IT里面又叫“进程”，虽然和进程相关，但直接叫“进程模型”会误导大家，所以我叫它“处理模型”，也就是和处理相关的设计。我们来看看“处理模型”阶段的任务： 1）进程、线程设计； 2）子系统设计； 为什么需要“处理模型”呢？相信看到上面的任务后，聪明的你应该已经知道了原因： 1）随着系统规模增大，处理性能要求增加，必须采用多进程多线程处理方式； 2）随着系统规模增大，复杂度增加，加上需要考虑可扩展性、可测试性、可靠性等质量属性，必须采用“分而治之”的方式划分子系统（注意此时还不是架构设计，欲知详情，请关注下一篇博文）； l 为什么现在才开始进行进程、线程、架构设计？ 讲到这里，估计很多朋友都有疑惑了：按照一般的经验，都是最开始就要进行子系统设计、进程线程设计的，怎么你的这个流程到现在才开始进行进程、线程、子系统设计呢？ 我们知道：进程、线程、子系统设计都必须有基础，而不是凭空创造或者想象出来的。那种所谓的先画一个圈表示系统、然后再在这个圈下面画几个圈表示子系统

一、前言 都说”不想做架构师的开发不是好前端“，”一千个读者心中有一千个哈姆雷特“。我相信每个开发者心中，都有一个属于自己的框架，所以今天我就给大家探讨一下我心中的简单分层架构设计。 在说分层架构设计之前，先说下我对架构设计的理解，不足之处还希望大神指点。《.NET应用架构设计》这本书里面写到：架构设计其实为“架构”和”设计”的两个概念，架构是对业务需求的高层抽象，而设计是将高层抽象的需求与具体的技术实现联系起来，在此过程中，会根据实际情况考虑到系统的稳定性、安全性、扩展性兼容性等各种因素。所以在项目业务需求提出之后，经过架构分析，得到系统的机构方案，然后根据架构方案做不同的设计方案，选择适合的设计方案进行开发。架构设计和代码重构一样，他不是一蹴而就的，他也是在迭代中变得完善和稳定。 说到这里，我想说一下框架和模式，平常中或多或少都会看到xx框架、xx模式，架构设计主要体现在设计上面，他们输出可能是文档或者伪代码等，而框架就是对架构设计的累计实现。比如工作中的项目框架，都是在我们经过多次设计、重构过后，得到公共模块（也就是我们说的轮子），在这个基础上，开发就会很便利。模式这是根据开发经验，提出某些问题比较好的解决方案。比如说单例模式、工厂模式等。 当然架构设计肯定没有说得这么简单，他还有很多设计原则和理论，感兴趣的朋友可以自己去了解一下。 下面就是蜗牛根据自己的理解

数据库架构设计 参考 数据库之互联网常用架构方案 数据库架构原则 架构核心的核心-数据库设计原则（金融行业） 海量数据存储--分库分表策略详解 来源： https://www.cnblogs.com/zhangchao0515/p/11493236.html

前言 题目有点大，所以不可能说得非常具体，笔者也不能驾驭全部。 前面介绍过 网站发展过程中架构的演化过程 ,本文主要针对网站架构各个方面的建设进行简单介绍。 架构模式 先来说说模式： 每一个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心。这样，你就能一次又一次地用该方案而不必做重复工作 。 先来说说常见的网站架构模式。这里没有涉及具体实现过程，只是简单介绍其思想和原理，方便日后有用到再深入了解。 分层 分层是企业应用系统中最常见的一种架构模式，将系统在 横向维度 上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后 通过上层对下层的依赖和调用 组成一个完整的系统。 分层 功能 应用层 负责具体业务和视图展示，如网站首页以及搜索输入和结果展示 服务层 为应用层提供服务支持，如用户管理服务，购物车服务 数据层 提供数据存储访问服务，如数据库、缓存、文件、搜索引擎等 分层架构 还可以细分下去 ，比如说应用层可以细分为视图层和业务逻辑层。服务层可以细分为数据接口层和逻辑处理层。 分层结构对网站支持高并发向分布式发展至关重要，所以 在网站规模很小的时候就应该采用分层的架构，这样将来网站做大时才能有更好地应对 。 所以说我们在设计一个新项目的架构时，就需要考虑到分层。不能等到日后项目做大了，再重构就耗时耗力了。 分割 上面的分层是将软件在横向方面进行切分，而分割是在

1、引言 本文以设计淘宝网的后台架构为例，介绍从一百个并发到千万级并发情况下服务端的架构的14次演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知。文章最后汇总了一些架构设计的原则。 2、程序员成长线 这是一条成长线的表意图，有两个部分：图上左侧的路径，是匹配不同成长阶段，对应不同职业角色；右侧是一条由不同成长阶段组成的成长线，包括如下： 征途：启程之初 修炼：程序之术 修行：由术入道 徘徊：道中彷徨 寻路：路在何方 蜕变：破茧成蝶 3、相关文章 《 新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践 》 《 腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面 》 《 一篇读懂分布式架构下的负载均衡技术：分类、原理、算法、常见方案等 》 《 快速理解高性能HTTP服务端的负载均衡技术原理 》 《 知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实践之路 》 《 达达O2O后台架构演进实践：从0到4000高并发请求背后的努力 》 《 小米技术分享：解密小米抢购系统千万高并发架构的演进和实践 》 《 通俗易懂：如何设计能支撑百万并发的数据库架构？ 》 4、基本概念 在介绍架构之前，为了避免部分读者对架构设计中的一些概念不了解，下面对几个最基础的概念进行介绍。 1）什么是分布式？ 系统中的多个模块在不同服务器上部署

「 OneAPM 技术公开课」由应用性能管理第一品牌 OneAPM 发起，内容面向 IT 开发和运维人员。云集技术牛人、知名架构师、实践专家共同探讨技术热点。本文系「OneAPM 技术公开课」第一期演讲嘉宾前当当网高级架构师吴英昊的演讲整理： 首先，非常感谢 OneAPM 技术公开课举办的这次活动。首先，我想说的是电商搜索引擎和普通的搜索引擎有很大的差别，因为电商搜索引擎主要是解决用户要「买什么」，而通用搜索引擎主要是解决用户「搜什么」。比如同样搜索一个词「百年孤独」，电商的搜索肯定是给你推荐这本书的商家，而百度主要是告诉你：《百年孤独》是一本书。 电商搜索引擎的特点 众所周知，标准的搜索引擎主要分成三个大的部分，第一步是爬虫系统，第二步是数据分析，第三步才是检索结果。首先，电商的搜索引擎并没有爬虫系统，因为所有的数据都是结构化的，一般都是微软的数据库或者 Oracle 的数据库，所以不用像百度一样用「爬虫」去不断去别的网站找内容，当然，电商其实也有自己的「爬虫」系统，一般都是抓取友商的价格，再对自己进行调整。 第二点，就是电商搜索引擎的过滤功能其实比搜索功能要常用。甚至大于搜索本身。什么是过滤功能？一般我们网站买东西的时候，搜了一个关健词，比如尿不湿，然后所有相关品牌或者其他分类的选择就会呈现在我们面前。对百度而言，搜什么词就是什么词，如果是新闻的话