架构设计

软件架构设计杂记: 分层架构 与 PO、VO、DTO、BO、POJO、BO/DO、DAO 原创： 陈光剑 Kotlin 开发者社区 前天 某位计算机大师说过: 计算机科学领域任何问题，都可以间接的通过添加一个中间层来解决. 什么是架构? 先引用《系统架构：复杂系统的产品设计与开发》里面的一句话： 结构良好的创造活动要优于毫无结构的创造活动。 架构始于建筑，是因为人类发展（原始人自给自足住在树上，也就不需要架构），分工协作的需要，将目标系统按某个原则进行切分，切分的原则，是要便于不同的角色进行并行工作。 一般而言，软件系统的架构（Architecture）有两个要素： 1.它是一个软件系统从整体到部分的最高层次的划分。 2.一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。 详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（TASk-flow）。所谓架构元素，也就是组成系统的核心"砖瓦"，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。 建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。 在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造

MSDN定义：枚举类型（也称为枚举）为定义一组可以赋给变量的命名整数常量提供了一种有效的方法。 例如，假设您必须定义一个变量，该变量的值表示一周中的一天。 该变量只能存储七个有意义的值。 若要定义这些值，可以使用枚举类型。枚举类型是使用 enum 关键字声明的。 从OOP上来说，枚举的角色和和class一样，它创建了一种新的数据类型。 1: namespace Enums 2: { 3: class Program 4: { 5: static void Main(string[] args) 6: { 7: } 8: } 9: 10: enum Color 11: { 12: Yellow, 13: Blue, 14: Brown, 15: Green 16: } 17: } 上面的代码，我们使用enum的关键字，创建了新的数据类型Color，并包含4个值： Yellow , Blue , Brown和 Green。下面的例子我们给予Color枚举。 直接输出枚举，则可得到枚举的字符 1: using System; 2: namespace Enums 3: { 4: class Program 5: { 6: static void Main(string[] args) 7: { 8: Console.WriteLine(Color.Yellow); 9: Console

依赖老旧系统方案设计 新建一个系统，该系统对老旧系统有依赖，也可能会相互依赖时，如何设计 整个考试模块从开始到现在，整个交互（系统功能提供着）调整4次，可谓变更之频繁。那为什么会产生这么多次变更呢，最主要的原因是没有一个整体的控制者，因为每一种方案的产出要考虑，几个方面：用户体验、未来规划、开发成本、工期要求，在考试这个事情上，用工和质检的合作是必然的趋势。但在协作模式上总是出现问题。从第一版的交互方案评审，业务的就产生新的功能要求，想页面文案啊，考试的具体功能啊，这些功能的实现与之前写的协作模式是违背的。所以一次次推翻了之前的方案。主要原因在于协作的方式过于耦合，职责不清晰，导致无法合理扩展。而今天的方案，恰好是这职责清晰的，满足业务功能的。我认为是可行的。符合设计模式。 来源： https://www.cnblogs.com/xiaogangfan/p/11365337.html

1.1. 什么是 Nginx Nginx 是俄罗斯人编写的十分轻量级的 HTTP 服务器 ,Nginx ，它的发音为 “engine X” ，是一个高性能的 HTTP 和反向代理服务器，同时也是一个 IMAP/POP3/SMTP 代理服务器。 Nginx 因为它的稳定性、丰富的模块库、灵活的配置和低系统资源的消耗而闻名．业界一致认为它是 Apache2.2 ＋ mod_proxy_balancer 的轻量级代替者，不仅是因为响应静态页面的速度非常快，而且它的模块数量达到 Apache 的近 2/3 。对 proxy 和 rewrite 模块的支持很彻底，还支持 mod_fcgi 、 ssl 、 vhosts ，适合用来做 mongrel clusters 的前端 HTTP 响应。 目前 Nginx 在国内很多大型企业都有应用，且普及率呈逐年上升趋势。选择 Nginx 的理由也很简单： 第一，它可以支持 5W 高并发连接； 第二，内存消耗少； 第三，成本低。 1.2. Nginx在架构中发挥的作用 网关 ---面向客户的总入口。 虚拟主机 --- 一台机器 为不同的域名/ip/端口提供服务 路由 ---使用反向代理，整合后续服务为一个完整业务 静态服务器 ---mvvm模式中，用来发布前端html/css/js/img 负载集群 ---使用upstream，负载多个tomcat

第四种模式： 分层API架构上事件驱动的状态管理 事件驱动并不是一个新的设计模式。许多ESB最初的设计模式就是一个事件驱动系统。当在微服务体系上实施事件驱动架构时，它能够提供一些强大的抽象。事件驱动系统通常使用某种类型的队列（类似于面向消息的系统），但是围绕队列所传递内容的设计和行为，强制执行一个标准；具体来说，就是事件。 人们经常将事件驱动模式与其他模式相混淆，因此在事件驱动模式中涵盖了大量的设计。严格地说，事件是关于过去发生的，具有相关代表性状态和时间戳的东西。事件允许接收它的服务通过按顺序重放事件来重建状态的物化视图。然而，在许多实现中，往往将事件（已经发生了的事情）与命令（让某件事情发生）混淆在一起。如果事件和命令不进行区分的话，架构设计的可预测性是有缺陷的。也就是说，不可否认，事件驱动的设计模式优于面向消息的方法（因为事件驱动的设计更为具体）；但是由于事件驱动的设计模式缺乏一致性，在实现中往往会出现问题。但是，鼓励并执行一致标准的团队会发现，事件驱动的设计模式能够在微服务体系结构中工作得很好。 问题： 为了确保系统内数据的完整性，需要复制关键业务事件，以便在微服务或数据存储之间进行同步。 解决方案： 使用常见的事件抽象来表示系统中的发生变化的组件。 应用： 当业务发生改变时，将其封装成过去时的事件，并发送给相关方。业务中的更改就是发送和处理这些事件的产物。 影响： 1

分层架构（layered architecture）是最常见的软件架构，也是事实上的标准架构。 如果你不知道要用什么架构，那就用它，可以用在业务上也可以用在技术上。这种架构将软件分成若干个水平层，每一层都有清晰的角色和分工，不需要知道其他层的细节，层与层之间隔离通过接口通信，串行依赖。 分层架构 核心点： 单向依赖，一层只依赖一层，不跨层 抽象隔离，分的越开越好，哪怕是异地 好处： 代码结构清晰易于理解 代码复杂度降低，容易理解和开发 层间隔离，利于排查问题 后期的维护升级方便而简单 每一层都可以独立测试，其他层的接口通过模拟解决 不同技能的程序员可以分工，负责不同的层，天然适合大多数软件公司的组织架构 抽象逻辑复用起来简单 分层思想的真理： 计算机科学领域任何问题，都可以间接的通过添加一个中间层来解决。 分层采用的方法： 单个项目的可采用package方式 com.xxx.core -- .service -- .mapper -- .util -- .controller -- .dao -- .model 多层项目的采用引入独立jar方式 paper-parent -- paper-common -- paper-core -- paper-core-api -- paper-core-service -- paper-rest 分层介绍 Web型项目的B

一、分层架构 分层架构是最常见的架构，也被称为n层架构。多年以来，许多企业和公司都在他们的项目中使用这种架构，它已经几乎成为事实标准，因此被大多数架构师、开发者和软件设计者所熟知。 分层架构中的层次和组件是水平方向的分层，每层扮演应用程序中特定的角色。根据需求和软件复杂度，我们可以设计N层，但大多数应用程序使用3-4层。有太多层的设计会很糟糕，将导致复杂度的上升，因为我们必须维护每一层。在传统的分层架构中，分层包括表现层、业务或者服务层，以及数据访问层。 表现层负责应用程序的用户交互和用户体验（外观和视觉）。通常我们会使用数据传输对象（Data Transfer Object）将数据带到这一层，然后使用视图模型（View Model）渲染到客户端。业务层接收请求并执行业务规则。数据访问层负责操作各种类型的数据库，每个访问数据库的请求都要经过这一层。 分层无需知道其他层如何去做，比如业务层无需知道数据访问层是如何查询数据库的，相反，业务层在调用数据层的特定方法时，只需关注需要部分数据还是全部数据。这就是我们所说的关注点分离。这是非常强大的功能，每层负责其所负的责任。 分层架构中的核心概念是管理依赖。如果我们使用依赖倒置原则和测试驱动开发(Test Driven Development)，我们的架构会有更好的健壮性。因为，我们要保证所有可能的用例都有测试用例。 我们需要这样的冗余

从头来设计一个画图的程序 B/S 架构的 先划分一下 model 层 多用户的model 层 单租户的session-model 层 view层 viewmodel 层 controller 相互解耦 不要互相知道对方 代码就是 dom.js DOM 树 添加图形 绘制 耦合 gdi 比暴漏dom 的数据细节要好 index.html view.js 一个很重要的优势 是不用自己处理局部更新问题 登记 激活 停止 事件委托 getMousePos 辅助方法 view 层在其中是承上启下的桥梁作用 所以边界设定非常重要 屏蔽平台的差异 定义页面布局 每个子系统负责什么事情？ 依赖哪些子系统 能够少知道一些子系统的存在吗？ 通过什么接口耦合的 这个接口是否自然体现了两者的业务关系？它们之间的接口是否足够稳定 来源： https://blog.csdn.net/ailinyingai/article/details/98962863

知名网站架构分析 探索Google App Engine背后的奥秘(1)–Google的核心技术 探索Google App Engine背后的奥秘(2)–Google的整体架构猜想 探索Google App Engine背后的奥秘(3)- Google App Engine的简介 探索Google App Engine背后的奥秘(4)- Google App Engine的架构 探索Google App Engine背后的奥秘(5)- Datastore的设计 探索Google App Engine背后的奥秘(6)- 总结 Amazon网站架构学习总结 Amazon网站架构学习总结 Amazon 的 Dynamo 架构 eBay 的应用服务器规模 eBay 的数据量 来自淘宝的架构经验 Yahoo！社区架构 基于Facebook和Flash平台的应用架构解析（一） 基于Facebook和Flash平台的应用架构解析（二） 基于Facebook和Flash平台的应用架构解析（三） Facebook图片存储架构的学习 facebook图片存储架构技术全解析 Facebook数据仓库揭秘：RCFile高效存储结构 Facebook 架构学习 Facebook 架构学习 人人网移动开发架构 QQ空间技术架构之深刻揭密 Twitter 的架构扩展: 100 倍性能提升

很多同学问做架构设计，怎么才能写出比较好的文档。其实很简单，都是有套路的，今天刚好借这个机会，和大家分享下一般做架构设计该怎么写文档。 背景 首先介绍下项目背景、基于什么原因需要需求。 如果是新产品，描述下产品启动的原因和背景、产品定位 如果是升级版本，描述升级需求、对原系统的影响，以及到达的预期效果 名词解释 文档中出现新的或者不常见的名词、概念给出定义和解释。 设计目标 实现功能 大致描述系统本身的功能性需求，不需描述外部依赖的系统。功能点之间的层级和关联关系要明晰。这里仅描述功能，不需要涉及实现方案、功能取舍等问题。 性能指标 描述系统性能需求。建议分条列出量化的性能指标，比如响应时间、超时率、资源占用、运行周期等。 系统环境 相关软件及硬件 在这里加入系统所需的软、硬件, 包括操作系统, 机器型号及配置要求。建议采用表格形式列出，最好还能规划出服务器和软件构件的部署图。 数据规模预估 通过经验或者调研，对数据规模进行估计，包括用户量、数据量、带宽消耗及增长速度等方面。 设计思路 描述系统设计中需要解决或考虑的关键问题或难点问题，解决这些问题可能有不同方案, 在这里加入方案设计的选择, 折衷及解释，并在后面的系统设计中对选中的方案给出进一步阐述。 建议分类列出，比如性能、可扩展性、安全性、服务稳定性、反作弊、复用等方面。建议使用调研数据支持设计方案的选择。 系统设计 基础介绍