架构设计

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

1. 面向对象架构设计 面向对象架构设计基础 面向对象架构设计流程 面向对象架构设计技巧 面向对象架构设计实践 2. 互联网技术架构 互联网技术发展之路 3. 面向业务的高可用架构设计 面向业务的高可用目标 立体化的高可用架构设计 客户端重试-HTTP-DNS 功能降级与服务降级 异地多活 业务立体化 4. 分布式技术架构 分布式存储 分布式计算 分布式协同调度 来源： oschina 链接： https://my.oschina.net/u/2858189/blog/727818

1、什么是架构和架构本质 在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。 LInux有架构，MySQL有架构，JVM也有架构，使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构，应该关注哪一个？想要清楚以上问题需要梳理几个有关系又相似的概念：系统与子系统、模块与组建、框架与架构: 一、系统与子系统 系统：泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能独立完成的工作能力的群体。 子系统：也是由一群关联的个体组成的系统，多半是在更大的系统中的一部分。 二、模块与组件 都是系统的组成部分，从不同角度拆分系统而已。模块是逻辑单元，组件是物理单元。 模块就是从逻辑上将系统分解， 即分而治之， 将复杂问题简单化。模块的粒度可大可小， 可以是系统，几个子系统、某个服务，函数， 类，方法、 功能块等等。 三、框架与架构 框架是组件的规范，例如：MVC、MVP、MVVM等，是提供基础功能的产品，例如：Ruby on Rails、Spring、Laravel、Django等。 框架是规范，架构是结构。 我在这重新定义架构：软件架构指软件系统的顶层结构。 架构是经过系统性地思考, 权衡利弊之后在现有资源约束下的最合理决策, 最终明确的系统骨架: 包括子系统, 模块, 组件. 以及他们之间协作关系,

如何设计出一个好的架构，不像数据公式或者定律，很难一概而就。很多时候是设计者（架构师）的各种设想，各种权衡折中而符合系统需求的智慧输出。但我们掌握前人总结的经验，让我们站在巨人的肩膀上高山远瞩。一些好的架构设计原则可以确保设计决策在一定程度上能够满足需求。 一、形成架构原则的过程 二、15条普适架构原则 《架构真经》这本书简单阐述了架构设计的一些常用的原则。罗列一些常用的原则，下面是15个具有普适价值架构原则 ： 1、N+1设计 ：开发的系统在发生故障时，至少有一个冗余的实例 广泛地应用在从数据中心设计到应用服务的部署： • 在发生故障时，系统至少要有一个冗余的实例。 • 必须确保一个为自己，一个为客户、 一个为失败 2、回滚设计 ：确保系统可以向后兼容。 1）如果很久才能修复服务，那么就要在一定的时间范围内完成回滚。 2）灾难性的事故，例如损坏客户数据，往往在部署后好几天才出现。 3）系统最好按照预先的设计，通过发布或回滚解决问题。 3、禁用设计：可以关闭任何发布功能 当设计系统，特别是与其他系统或服务通讯的高风险系统时，要确保这些系统能够通过开关来禁用。这将为修复服务提供额外的时间，同时确保系统不因为错误引起诡异需求而宕机。 4、监控设计 :在设计阶段就要考虑监控，而不是在部署完成后。 通过监控发现系统的可用性问题。 • 通过监控使系统自我诊断、自我修复成为可能。 •

XMind 是一款头脑风暴软件，下图是程序界面 但是，最近，发现，原来它还可以拿来做需求分析、架构设计、数据库设计等工作。界面美观、描述丰富，非常不错。看看几个使用案例： eg. 数据库设计 示例； 数据库的设计不使用正向工程自动生成，而选择使用SQL语句创建。对于编程人员来说，需要知道数据库的关系结构、字段类型、物理名称。这个已经足够了！ 转载于:https://www.cnblogs.com/AthsonWang/archive/2010/08/09/1795658.html 来源： https://blog.csdn.net/weixin_30653097/article/details/99925895

菩提树下的杨过 ： ZooKeeper 笔记(1) 安装部署及hello world ZooKeeper 笔记(2) 监听数据变化 ZooKeeper 笔记(3) 实战应用之【统一配置管理】 ZooKeeper 笔记(4) 实战应用之【消除单点故障】 ZooKeeper 笔记(5) ACL(Access Control List)访问控制列表 ActiveMQ笔记(2)：基于ZooKeeper的HA方案 ZooKeeper 笔记(6) 分布式锁 sunddenly ： ZooKeeper学习第一期---Zookeeper简单介绍 ZooKeeper学习第二期--ZooKeeper安装配置 ZooKeeper学习第三期---Zookeeper命令操作 ZooKeeper学习第四期---构建ZooKeeper应用 ZooKeeper学习第五期--ZooKeeper管理分布式环境中的数据 ZooKeeper学习第六期---ZooKeeper机制架构 ZooKeeper学习第七期--ZooKeeper一致性原理 ZooKeeper学习第八期——ZooKeeper伸缩性 横刀天笑的碎碎念 ： Zookeeper--Zookeeper是什么 Zookeeper-Zookeeper可以干什么 Zookeeper-Zookeeper的配置 Zookeeper-Zookeeper启动过程

多视图的方法不仅仅是架构归档技术，更是指导我们进行架构设计的思维方法。 越是复杂的系统，越是需要从多个方面进行架构设计，这样才能把问题研究和表达清楚，而提供不同的软件架构视图也便于交流和传递设计思想。 关键需求是对软件架构设计起关键作用的需求子集，包括功能需求、质量需求和商业需求三种，架构细化必须注意满足这些需求。 领域模型是以面向对象方式对问题领域的模型的模拟和抽象，它揭示了重要的业务领域概念，并建立业务领域概念之间的关系，领域模型被不断精化后成为最终软件系统的问题领域层，它决定了软件系统的功能范围，并影响着软件系统的可扩展性。 概念性架构是对系统设计的最初构想，通过主要的设计元素及它们之间的关系来描述系统，这些高层次的设计选择对未来软件系统的质量和功能都有关键作用。 约束可以视为一类特殊的需求，它们具有强制性，规定了业务和技术上的标准和限制。 我们利用架构视图的方法，从逻辑架构、开发架构、运行架构、物理架构和数据架构五个方面来进行架构设计。 设计逻辑架构：使用 UML 来描述，静态方面包括包图、类图、对象图；动态方面包括序列图、协作图、状态图和活动图。 逻辑架构的设计应该完成的工作： 细化功能单元 发现通用机制 细化领域模型 确定子系统接口和交互机制 因为软件架构的重点在于‘软件系统的各部分是如何相关的’，那么我们可以经过适度的抽象分析，将几组协作中的公共行为提取出来成为

　　软件架构概述 　　软件架构是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件。处理构件负责对数据进行加工，数据构件是被加工的信息，连接构件把架构的不同部分连接起来。软件架构是软件设计过程的一个层次，这一层次超越计算过程中的算法设计和数据库设计。架构问题包括总体组织和全局控制、通信协议、同步、数据存取，给设计元素分配特定功能，设计元素的组织，规模和性能，在各设计方案间进行选择等。软件架构处理算法与数据结构之上关于整个系统结构设计和描述方面的一些问题，如全局组织和全局控制结构、关于通信、同步与数据存取的协议，设计构件功能定义，物理分布于合成，设计方案的选择、评估与实现等。 　　软件架构包括一个或一组软件构件、软件构件的外部的可见特性及其相互关系。其中，“软件外部的可见性”是指软件构件提供的服务、性能、特性、错误处理、共享资源等。对于复杂系统和大型系统的开发而言，设计好软件架构是保证软件质量的根本措施。具体来说，软件架构具有以下作用： 　　（1）软件架构是项目干系人进行交流的手段。 　　（2）软件架构是早期设计决策的体现。 　　（3）软件架构是可以传递和可复用的模型。 　　软件架构建模 　　设计软件架构的首要问题是如何表示软件架构，即如何对软件架构建模。根据建模的侧重点不同，可以将软件架构的模型分为5种，分别是结构模型、框架模型、动态模型、过程模型和功能模型。

1. 逻辑架构 逻辑架构的重点是考虑软件功能性需求。 No. 考虑的方面 产出物 工具 说明 1 系统功能划分为几个子系统与功能模块？ 系统功能树 树型结构图 2 向什么用户提供什么样的功能？ 用例模型 UML用例图 体现用户和行为 3 每个功能都是怎样的操作流程与分支？ 用例描述 用例描述表 含输入输出、事件流分析； 不要有界面描述 UML活动图 进行业务流程分析，包括泳道图 4 如何通过界面与用户交互？怎样交互？ 鲁棒分析 鲁棒图 通过对“用例描述表”进行原文分析法拣出名词和动词 5 应当设计哪些类与界面？怎样设计？ 领域模型 UML类图 6 与哪些外部系统接口？怎样接口？ 接口描述 UML类图 2. 开发架构 开发架构重点关注的是开发编码实现方面的问题。 No. 考虑的方面 产出物 工具 说明 1 分层结构设计 分层架构图（开发架构图） 各种绘图工具 好的分层结构支持自动化测试 2 开发技术选项 开发语言 开发框架 开发工具 考虑商用产品、开源框架、自研框架 3 模块划分 源码工程；Project目录结构； 分包(分库) 4 开发规范 开发/编码规范文档； 5 软件质量属性 分析和决策结果 考虑运行期和开发期软件质量属性，并权衡利弊进行决策。 3. 数据架构 数据架构不仅仅要考虑开发中涉及到的数据库，实体模型，也要考虑物理架构中数据存储的设计。 No. 考虑的方面 产出物

架构设计和概要设计 (2012-09-11 21:35:57) 转载 ▼ 标签： 架构设计 概要设计 分类： 随笔文章 初步再来探讨下架构设计和概要设计的区别和边界问题。先谈下架构设计： 架构设计包括了功能性架构和技术架构设计两个部分的内容，功能性架构解决业务流程和功能问题，而技术架构解决非功能性需求等问题。两种架构都包括了动态和静态两个方面的内容，对于功能性架构中动态部分为业务流程驱动全局用例，用例驱动的用例实现等；对于技术架构中动态部分为架构运行机制，而静态部分为框架，分层等方面的内容。 功能性架构包括了全局用例设计，这个本身是用例分析和设计的一个延续，而全局用例分析建议的思路仍然是业务流程，业务用例建模到系统用例建模的过程。全局用例分析清楚后可以开始考虑子系统和模块的划分，形成系统的功能架构图，当然在划分过程中一定要考虑到通过CRUD矩阵等分析方法来分析模块如何划分合理，如何保证模块本身高内聚和松耦合。 在全局用例分析完成后涉及到数据模型的设计，数据建模仍然从业务驱动，从最初的业务对象和单据入手，到最终的数据概念模型和逻辑模型等。架构设计中全局数据模型不一定覆盖所有的数据对象和数据表；但是核心的主数据，核心业务单据数据一定要覆盖到，模型到的层次到逻辑模型即可。如果用面向对象的分析方法，这里需要出的是UML建模中的概念模型和逻辑模型，体现核心对象和类，核心对象和类之间的关系。