架构设计

模式的经典定义：每个模式都描述了一个在我们的环境中不断出现的问题，然后描述了该问题的解决方案的核心，通过这种方式，我们可以无数次地 重用 那些已有的解决方案，无需再重复相同的工作。即模式是在特定环境中解决问题的一种方案 。 什么是架构模式？在维基百科：架构模式是针对特定软件架构场景常见问题的通用、可重用解决方案。架构模式类似于软件设计模式，但范围更广。 架构的本质是管理复杂性。 如果你觉得架构不重要，可能是你做的事情不够复杂，或者是你没有管理好复杂性。架构模式虽多，经过抽象沉淀之后，也就那么几种，O'Reilly 出版过一本免费的小册子《Software Architecture Patterns》， 介绍了五种最常见的软件架构，是非常好的入门读物： 1. 分层架构（比较传统的单体架构） 2. 微服务架构（服务分割：当前比较流行的服务化架构，解决单体架构面临的问题，适合敏捷开发，快速迭代） 3. 微核架构（又称插件架构，开发难度较高，一般用来做工具软件开发，如Eclipse，不太适合分布式业务场景） 4. 事件驱动架构 （一般适用于应用局部场景，用来实现异步解耦） 5. 云架构（现在的说法是云原生架构-Cloud Native，基于Docker、Kubernetes、Service Mesh 云原生架构） 一、分层 分层架构（ layered architecture

转自： https://blog.csdn.net/zhonglunsheng/article/details/83153451 简单的说，微服务是架构设计方式，分布式是系统部署方式，两者概念不同 微服务是啥？ 这里不引用书本上的复杂概论了，简单来说微服务就是很小的服务，小到一个服务只对应一个单一的功能，只做一件事。这个服务可以单独部署运行，服务之间可以通过RPC来相互交互，每个微服务都是由独立的小团队开发，测试，部署，上线，负责它的整个生命周期。 微服务架构又是啥？ 在做架构设计的时候，先做逻辑架构，再做物理架构，当你拿到需求后，估算过最大用户量和并发量后，计算单个应用服务器能否满足需求，如果用户量只有几百人的小应用，单体应用就能搞定，即所有应用部署在一个应用服务器里，如果是很大用户量，且某些功能会被频繁访问，或者某些功能计算量很大，建议将应用拆解为多个子系统，各自负责各自功能，这就是微服务架构。 那么分布式又是啥？ 分布式服务顾名思义服务是分散部署在不同的机器上的，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是通过rpc来交互或者是webservice来交互的。逻辑架构设计完后就该做物理架构设计，系统应用部署在超过一台服务器或虚拟机上，且各分开部署的部分彼此通过各种通讯协议交互信息，就可算作分布式部署，生产环境下的微服务肯定是分布式部署的

架构设计 软件架构是指在一定的设计原则基础上，从不同角度对组成系统的各部分进行搭配和安排，形成系统的多个结构而组成架构，它包括该系统的各个组件，组件的外部可见属性及组件之间的相互关系。组件的外部可见属性是指其他组件对该组件所做的假设。 一、架构设计过程 业界软件架构设计的方法论很多，各有各自的应用场景和特点，下文结合ADMEMS（Architecture Design Method has been Extended to Method System）架构设计方法论说明软件架构的过程： 预架构阶段 目标：全面理解需求；需求结构化，摒弃“需求列表”，建立二维需求观（ADMEMS矩阵）。 方法：使用ADMEMS矩阵方法，捋清需求间关系和发现衍生需求。 具体步骤： 1、与人：与项目经理、需求分析师等内部需求人员了解需求；与客户了解需求（不建议架构师做需求分析师角色）。 2、与物：了解《需求规格说明书》等需求文档。" 3、对需求有什么问题，反馈给售前或销售，可能会参与拜访客户或电话会议。 4、销售或售前有时会要求提供一个大致的工作量，以便他们初步评估项目可行性。 概念架构 目标：高层组件及其关系 方法： 1、初步设计，基于关键功能，借助鲁棒图进行以发现职责为目的的初步设计（不是必须）。 2、高层分割，将复杂系统切分为多个二级系统或多个子系统。 3、考虑非功能需求，采用ADMEMS推荐的目标

　　近段时间，一直在负责一个产品版本改造（C/S系统进行B/S改造）的研发项目管理，在任务紧、时间短、团队成员又没有相关技术（Silverlight）背景的恶劣情况下，我带领包含我在内只有6个人员（5个研发人员，1个产品经理，产品经理在系统版本改造中主要精力投入到辅助市场部进行产品推广去了）的超小型项目团队，终于在公司给定的时间范围内完成了整个产品的版本改造。这其中经历了需求变更、技术风险、人员变动等诸多问题，项目任然取得了成功，这种使用新技术的试验项目能够取得成功不得不说有几分侥幸，更多的还是团队兄弟之间的互相帮助、团队协作。 　　在历时3个月的产品版本改造过程中，经历了大大小小的诸多问题，积累了一些经验和教训可以和大家分享。其中主要包括：需求、设计、研发、测试、实施、进度、风险、沟通、团队管理等。由于刚涉入研发项目管理，很多方面都做得不到位，于此记录下本次产品版本改造中的点点滴滴，在以后的工作开展中以此为戒，希望可以将项目管理做得更好。 　　大家都知道，无论什么项目都应该以需求为核心，分析、理解清楚所有的目标需求以及潜在的需求，以研发出一套能够得到客户满意的软件产品，那么项目就可以算是成功了。不同的项目环境的需求也是不一致的，就我这边的项目情况，其需求主要体现在：成本需求、软件环境需求、软件功能需求等。 　　1）、成本需求 　　　　成本需求主要是在人力、物力、财力、时间等方面

愿景已经确定架构愿景和目标。 需求分析明确架构要解决当前什么问题。 那接下来就是如何着手开始做架构设计。 一、如何开始设计一个架构：方式方法 架构不是像平常写代码一样，对就是对，错就是错，它并无对错之分，是一个取舍的过程。当我们从0开始做架构的时候，的确是比较困难。虽然万事开头难，但是一个好的开始相当于成功了一半，会给我们接下去的工作打下结实的基础。 我的经验步骤是：业务->功能->技术实现->架构综览图 1、业务架构:确定总体架构，核心流程, 是最上层的战略架构. 包括业务规划，业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。 没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往会给系统带入大坑，任何不基于业务做异想天开的架构都是耍流氓。 所有问题的前提要搞清楚我们今天面临的业务量有多大，增长走势是什么样，而且解决高并发的过程，一定是一个循序渐进逐步的过程。 合理的架构能够提前预见业务发展1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。 2、应用架构:确定子系统的功能范围和划分解决方案: 应用作为独立可部署的单元，为系统划分了明确的边界，深刻影响系统功能组织、代码开发、部署和运维等各方面. 应用架构定义系统有哪些应用、以及应用之间如何分工和合作

架构设计需求分析: 主要目的是明确架构要解决当前什么问题， 先调研需求方的诉求。 如果公司的架构部自high，做一些根本没有人使用的框架，组件，系统: 以“晋升”为目的的架构设计都应该拉出去祭天。 脱离业务的架构设计都是耍流氓。 一、架构设计的需求分析从哪来 需求分析的前期工作是愿景描述及愿景分析, 即愿景分析就是需求的前期调研. 从软件过程来看，需求分析是一个承上启下的阶段–“上承”愿景，“下接”设计。需求分析的工作内容包含如下三方面： 需求捕获: 理解沟通 需求分析:做什么,有哪些问题 系统分析:原因是什么, 怎么做 三者不是独立无关的阶段，而是相互伴随、交叉进行的。 需求捕获: 从各个方面收集需求, 并理解需求.典型的需求捕获是使用“需求采集卡”：需求描述、需求提出者、需求记录者、需求类型等。 需求分析: 需求捕获得到的是“原始需求”，而需求分析则对各方面收集到的需求进行分析、整理、归纳、论证形成明确的需求。比如, 产品经理说,现在系统不稳定, 需要重构架构保证系统稳定. 这只是一个愿景, 我们需要把这个需求形成一个明确的需求: 可行性99.99%, 要完成这个指标,需要做哪些工作. 二、需求分类:需求结构化 收集需求是多而杂, 我们需要理解并整理, 通过二维需求观，将“需求=列表”的传统观念，一下子拓宽了维度。有了视野和思维上的提升。 二维需求观: 首先，需求是分层次的:

此系列文章为 极客时间 上 从 0 开始学架构 学习后感悟总结，虽然隔了一段时间了，那么就再看一遍并且进行感悟升华，排版格式上有问题，后期再复习时也会进行更新 架构设计的关键思维是判断和取舍，程序设计的关键思维是逻辑和实现。 架构设计的主要目的是为了解决软件系统复杂度带来的问题，架构师该做的有的放矢，而不是贪大求全 一.架构复杂度来源---高性能 为了满足业务的所需性能，单机早已无法应当，因此都是采用集群方式来应对，使用集群方式后就会变得更复杂。 很简单的方式，我们加入新机器后便需要再加入任务分配器，从单机就进化成了下图，很好理解 　　 　　 　　随着为了满足业务性能要求增加了新服务器后，引出了一些问题 多了一个任务分配器，它可能是硬件（F5），也更有可能是负载均衡软件（lvs/nginx/haproxy），也可能是自研系统 任务分配器内有算法，使用不同的算法会对我们的性能有不同的改善，不同的业务场景有各自所需的算法 任务分配器与后端业务机器之间的联通问题 一台机器可以承受5000业务量（假定），但是2台并不是1W，实际需要打个8折，即8000，如果业务还比较复杂，那么可能只有5000，我们的收益会越来越低 随着业务量的增加，单台任务分配器都会成为瓶颈，即连任务分配器我们也需要变成集群模式，任务分配器前面也需要选择对应的分配策略（即任务分配器的任务分配器），常用的有DNS 轮询

第2章 什么影响了MySQL性能 2-1 影响性能的几个方面 1、服务器的硬件 2、服务器的操作系统 3、数据库的存储引擎 4、数据库的参数配置 5、数据库表结构设计和SQL语句的编写和优化 2-2 CPU资源和可用内存大小 2-03 磁盘的配置和选择 2-04 使用RAID增加传统机器硬盘的性能 2-05 使用固态存储SSD或PCIe卡 2-06 使用网络存储SAN和NAS 2-07 总结：服务器硬件对性能的影响 2-08 操作系统对性能的影响-MySQL适合的操作系统 Windows、FreeBSD、Solaris Linux、CentOS 2-09 CentOS系统参数优化 来源： https://www.cnblogs.com/MarlonKang/p/12230632.html

Druid 的目标是提供一个能够在大数据集上做实时数据消费与探索的平台。对普遍的数据平台来说，数据的高效摄入与快速查询往往是一对难以两全的指标，但Druid 是怎么做到的呢？这很大程度上得益于其独到的架构设计和基于DataSource 与Segment 的数据结构。 对于目前大多数Druid 的使用场景来说，Druid 本质上是一个分布式的时序数据库，而对于一个数据库的性能来说，其数据的组织方式至关重要。为了更好地阐述Druid 的架构设计思想，我们得先从数据库的文件组织方式聊起。 众所周知，数据库的数据大多存储在磁盘上，而磁盘的访问相对内存的访问来说是一项很耗时的操作，对比如下。因此，提高数据库数据的查找速度的关键点之一便是尽量减少磁盘的访问次数。 磁盘与内存的访问速度对比 为了加速数据库数据的访问，大多传统的关系型数据库都会使用特殊的数据结构来帮助查找数据，这种数据结构叫作索引（ Index）。对于传统的关系型数据库，考虑到经常需要范围查找某一批数据，因此其索引一般不使用 Hash算法，而使用树（ Tree）结构。然而，树结构的种类很多，却不一定都适合用于做数据库索引。 索引对树结构的选择 1.二叉查找树与平衡二叉树 最常见的树结构是二叉查找树（ Binary Search Tree），它就是一棵二叉有序树：保证左子树上所有节点的值都小于根节点的值

如果你对项目管理、系统架构有兴趣，请加微信订阅号“softjg”，加入这个PM、架构师的大家庭 业务逻辑层是专门处理软件业务需求的一层，处于数据库之上，服务层之下，完成一些列对Domain Object的CRUD，作为一组微服务提供给服务层来组织在暴露给表现层，如库存检查，用法合法性检查，订单创建。 业务逻辑层包含领域对象模型，领域实体，业务规则，验证规则，业务流程。1：领域对象模型为系统结构描述，包含实体功能描述，实体之间的关系。领域模型处于天生的复杂性:2：领域实体：业务层是一些操作业务对象（BO）的处理。业务对象包含数据和行为，是一个完整的业务对象。其不同于上节架构设计中服务层的简单理解提到的数据迁移对象（dto），对于dto存在数据的，不存在行为，dto是bo（ddd中又称do）的子集，负责与特定界面需求的扁平化实体，dto仅仅是一个数据载体，需要跨越应用程序边界，而业务对象则不会存在复制迁移，往往一个业务对象存在一个或者多个数据迁移对象。3:业务最大的逻辑就在处理一些列现实世界的规则，这也是软件中最容易变化的部分，这里通常会出现我们众多的if-else或者switch-case的地方。也这因为如果说以个人觉得在我们的项目最应该关系和分离需求的层次。4：验证规则：业务规则很大程度上也是对对象的数据验证，验证业务对象的当前数据状态