架构

什么是超融合？ “超融合”这个概念，可以简单理解为：将虚拟计算平台和存储融合到一起，将每台服务器里面自带的硬盘组成存储池，以虚拟化的形式提供数据中心所需要的计算、网络、安全以及存储等IT基础架构。在这里，也讲解一下超融合相对于传统虚拟化方案的优势。 横向与纵向的扩展性 顾名思义，横向扩展就是当发现存储和计算资源不够用了，按需添加服务器即可。比如，当用户的共享存储写满了，用户不得不花大价钱去购买一个新的存储机柜，然而此时存储机柜的资源利用率是很低的。而使用超融合方案的用户，他们只需要投入较少的费用去购买一个新的服务器加入集群，即可扩展存储空间。 便捷提供多副本，提高数据安全 超融合方案可便捷支持2-3个副本。当某些服务器损坏时，若采用超融合方案，所需要的数据还会存在对应的副本里，工作还能正常进行。而对比于传统的共享存储，用户想做两个副本时，只好硬着头皮再买一个一模一样的存储设备做备份，增加了不少IT投资。 分布式存储，拉近计算和存储的距离 传统的共享存储在数据读写时，都需要通过网线或光纤进行数据传输。而超融合分布式的存储在读数据的时候，基本都是直接读取本地的副本数据，减少数据流经网线或光纤的时间，加快数据读取速度。 软硬件一体化，省钱省力省心 超融合方案所支持的软硬件一体化，即用户可以一次性轻松地把云数据中心部署好，其中包括服务器、服务器虚拟化、存储虚拟化等虚拟化软件

简单的3层架构： bean:javabean 　　实体类，负责在各层间传输数据 service:服务类 　　业务逻辑 view:视图类 　　界面的展示 　　接收用户输入 　　把结果显示给操作人员 utils:工具类 test:测试类 来源： https://www.cnblogs.com/start-from-scratch/p/12598671.html

软件架构的历程 计算机科学的发展历程可以追溯到第一代电子管计算机（1945年~1956年）。1946年2月15日世界上第一台重达30顿的计算机ENIAC（Electronic Numerical Integrator and Computer）正式在费城公布于世，它标志着现代计算机科学的诞生。 相比来说，计算机软件架构的发展就更晚。从20世纪80年代晚期开始，整个计算机科学界为了应对大规模系统设计所带来的复杂度，才逐渐开始了软件架构的研究工作。因为先前的系统架构和设计是严重依赖相关人员各不相同的实践经验和观察，并不能客观地衡量和控制架构活动的质量。 历经了十几年的不懈努力，软件架构的研究逐步走向了成熟。当今较为成熟的架构技术已经包含了很多方面的研究成果：标注语言的使用、大量的设计工具、问题分析技术、架构设计技术和手段、复杂系统设计和开发的指南等。同时当今的架构技术已经与其他相关领域的研究成果进行了很好的融合：软件产品家族（Software Product Family）的研究、领域驱动（Domain Driven）的设计技术、基于构件重用的技术等。这些成果的结晶，成为当今复杂系统设计强有力的武器，确保系统设计的质量受到严格的控制。 在我们系统化地回顾整个这十几年人类在软件架构方面的伟大成就之前，我们要先介绍一种技术成熟度的评估模型。因为从讲求科学性的工程的角度上来看

什么是微服务 微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。 微服务的概念源于2014年3月Martin Fowler所写的一篇文章“Microservices”( http://martinfowler.com/articles/microservices.html )。 尽管“微服务”这种架构风格没有精确的定义，但其具有一些共同的特性，如围绕业务能力组织服务、自动化部署、智能端点、对语言及数据的“去集中化”控制等等。微服务架构的思考是从与整体应用对比而产生的。 通常，在一家公司随着业务需求的增长为逐步发展（自然增长）的过程中，前期往往是以单块架构的方式来组织系统的。因为对于软件的初期构建来说，单块架构的方式是最容易且最高效的。但是若干年（甚至是几个月）后，受限于前期既有单块软件系统内部耦合性，再向该系统加新功能变得越来越艰难。 单块软件 企业应用，因为服务于众多业务需求，因此会有些特定的软件应用提供许多功能，而一般惯例是把这些功能都堆在单个单片应用中。例如，ERP，CRM和其他各种软件系统被规划构建为具有数百个功能的整体。这种带坑应用一经部署，在往后的故障排除、扩展和升级场景中就是一场接一场的恶梦了。

也许很多人还不知道，知乎在规模上是仅次于百度贴吧和豆瓣的中文互联网最大的UGC（用户生成内容）社区。知乎创业三年来，从0开始，到现在已经有了100多台服务器。目前知乎的注册用户超过了1100万，每个月有超过8000万人使用；网站每个月的PV 超过2.2亿，差不多每秒钟的动态请求超过2500。 在ArchSummit全球架构师峰会上，知乎联合创始人兼CTO李申申带来了知乎创业三年多来的首次全面技术分享（ 演讲视频 ）。本文系根据演讲内容整理而成。 初期架构选型 知乎的主力开发语言是Python。因为Python简单且强大，能够快速上手，开发效率高，而且社区活跃，团队成员也比较喜欢。 知乎使用的是Tornado框架。因为它支持异步，很适合做实时Comet应用，而且简单轻量，学习成本低，再就是有FriendFeed的成熟案例，Facebook的社区支持。知乎的产品有个特性，就是希望跟浏览器端建立一个长连接，便于实时推送Feed和通知，所以Tornado比较合适。 最初整个团队的精力全部放在产品功能的开发上，而其他方面，基本上能节约时间、能省的都用最简单的方法来解决，当然这在后期也带来了一些问题。 最初的想法是用云主机，节省成本。知乎的第一台服务器是512MB内存的Linode主机。但是网站上线后，内测受欢迎程度超出预期，很多用户反馈网站很慢。跨国网络延迟比想象的要大

概述 在学习OpenStack的过程中，感觉对整个OpenStack的架构稍稍有些了解，所以将这些记录下来，一来防止自己忘记，二来也可以对有需要的人提供帮助 本文章相关的灵感/说明/图片来自于https://github.com/yongluo2013/osf-openstack-training/blob/master/installation/openstack-icehouse-for-centos65.md 首先放几张图，详细的解释了OpenStack的架构以及网络拓扑结构. 架构 拓扑 Openstack架构详解 整个OpenStack由控制节点，计算节点，网络节点，存储节点四大部分组成 控制节点负责了对其余节点的控制，包含虚拟机建立，迁移，网络分配，存储分配等等 计算节点负责了虚拟机运行 网络节点负责了对外网络与对内网络之间的通信 存储节点负责了对虚拟机的额外存储管理等等 以下架构仅为本人理解，不尽完全，如有错误欢迎指出 控制节点架构 控制节点包括以下服务 管理支持服务 基础管理服务 扩展管理服务 管理支持服务包含MySQL与Qpid两个服务 MySQL：数据库作为基础/扩展服务产生的数据存放的地方 Qpid：消息代理(也称消息中间件)为其他各种服务之间提供了统一的消息通信服务 基础管理服务包含Keystone，Glance，Nova，Neutron

http://blog.csdn.net/huwei2003/article/details/51392131 1)需求的抽象、转换；2）系统分解；3）设计模型建立；4）框架技术选型；5）技术风险排查； 主要职责：将需求转化为编码说明书。 架构师的职责主要有如下4条： 　　1、确认需求 　　在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。架构师需要和分析人员反复交流，以保证自己完整并准确地理解用户需求。 　　2、系统分解 　　依据用户需求，架构师将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务。随后，架构师会确定各层的接口，层与层相互之间的关系。架构师不仅要对整个系统分层，进行“纵向”分解，还要对同一逻辑层分块，进行“横向”分解。 　　软件架构师的功力基本体现于此，这是一项相对复杂的工作。 　　3、技术选型 　　架构师通过对系统的一系列的分解，最终形成了软件的整体架构。技术选择主要取决于软件架构。 　　Web Server运行在Windows上还是Linux上？数据库采用MSSql、Oracle还是MySQL？需要不需要采用MVC或者spring等轻量级的框架？前端采用富客户端还是瘦客户端方式？类似的工作，都需要在这个阶段提出，并进行评估。 　　架构师对产品和技术的选型仅仅限于评估，没有决定权，最终的决定权归项目经理

一架构师职责 架构师是一个既需要掌控整体又要洞悉局部瓶颈，并依据具体的业务场景给出解决方案的团队领导型人物，他需要参与项目开发的全部过程，包括需求分析、架构设计、系统实现、集成、测试和部署各个阶段，负责在整个项目中对技术活动和技术说明进行指导和协调。 架构师主要职责有4条： 01确认需求 在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。架构师需要和分析人员反复交流，以保证自己完整并准确地理解用户需求。 02系统分解 依据用户需求，架构师将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务。随后，架构师会确定各层的接口，层与层相互之间的关系。架构师不仅要对整个系统分层，进行“纵向”分解，还要对同一逻辑层分块，进行“横向”分解。 架构师的功力基本体现于此，这是一项相对复杂的工作。 03技术选型 架构师通过对系统的一系列的分解，最终形成了软件的整体架构。技术选择主要取决于软件架构。Web Server运行在Windows上还是Linux上？数据库采用MSSql、Oracle还是Mysql？需要不需要采用MVC或者Spring等轻量级的框架？前端采用富客户端还是瘦客户端方式？类似的工作，都需要在这个阶段提出，并进行评估。 架构师对产品和技术的选型仅仅限于评估，没有决定权，最终的决定权归项目经理

1.三层架构： 说明： A.UI依赖于IBLL,UI通过BLL层的唯一入口（门面模式、工厂模式）来获得相应的业务服务对象（业务服务对象以业务为原则创建，比如：处理用户相关的业务，可定义UserService类）；UI层不应包含任何的逻辑代码（最多只允许包含一部份与UI相关的逻辑） B.BLL层中处理UI发过来的请求，并及时进行相应的处理（数据验证，向DAL层发送查询数据或持久化数据等），处理后返回UI所需的资源；BLL层依赖于IDAL，同样BLL通过DAL层的唯一入口（门面模式、工厂模式）来获得相应的数据访问对象（数据访问对象以业务所需数据或数据表为原则创建，比如：支付，可定义：PayDao类，类中包含账号信息、付款人信息、金额等）； C.DAL层处理BLL层发过来的请求，并及时向DB发送查询数据或保存数据的命令，获得资源后返回给BLL层； 2.MVP架构： 说明： A.UI层（即：VIEW层）依赖于IPresenter接口，同时实现IView接口；UI层需初始化相应的Presenter对象，并将自己传给Presenter对象；被动接收Presenter的处理请求； B.Presenter依赖于IView接口，同时实现IPresenter接口，Presenter主动处理UI层反馈的请求（UI层向Presenter反馈的方法：一是VIEW中定义响应事件委托

来源： https://www.cnblogs.com/imaikce/p/12310202.html