架构

学习目标 　　听<软件架构相关音频>软件开发架构一节 待解决问题 　　构件的概念 ? 　　如何表达一个项目的架构,用什么图表? 　　架构设计作为一个系统开发的中间产品,交付的是什么内容? 　　各种架构风格的适用场景? 学习内容(耗时:40min) 软件架构是什么 　　软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述，构建的相互作用（连接件）、知道构件集成的模式以及这些模式的约束组成。软件架构不仅指定了系统的组织架构和拓扑结构，并且显示了系统需求和构建还见的对应关系，提供了一些设计决策的基本原理 架构设计的重要性 架构设计好比房子的钢筋水泥,定下了结构,才能撑的起整个系统.尤其是在大型软件开发中 软件架构的重要性越来越大 需求分析 -- 〉 架构设计 --〉 软件分析 软件架构 应该是项目中的一个可交付的中间产品 　　 软件架构的意义(9个意义 ) 架构是项目干系人进行交流的手段 架构是早期设计决策的体现 架构明确了对系统实现的约束条件 架构决定了开发和维护组织的组织结构 架构制约着系统的质量属性 架构使推理和控制更改更监督 架构有助于循序渐进的原型设计 架构可以作为培训的基础 架构是可传递和可服用的模型　 架构的发展阶段(4个阶段) 无架构设计阶段 萌芽阶段 初级阶段 高级阶段 　　 如何表示软件架构(软件架构建模) 　　　　 结构模型（常用） 核心

为什么要去Oracle 现在好像是个互联网公司好像都在谈去IOE，也有人问过我们，去IOE到底有什么受益？我们公司为什么要去IOE呢？当然实际情况是因为我们上层领导决定的，所以我们都热火朝天的干起来了，就跟我们当时为什么将已经开发的系统从MySQL数据库改成Oralce一样，都是上层领导决定的。对此我只能哈哈哈了。 但是我有自己的思考，为什么我们要去Oracle呢？对我们到底会带来什么受益呢？我个人觉得对于大型互联网公司用MySQL替代Oracle的原因有这样一些。 大规模部署成本可大幅度降低 因为大型互联网公司往往存储非常大规模的数据，数据库的读写流量也往往巨大，有数以千计的各种应用都需要用到数据库，这样购买硬件、软件license的成本巨大，随着业务不断发展，部署规模不断增加，我们的成本也将持续增加，这个帐应该很简单，不必细算。因此从成本考量我们是动力去做这个改造的。 但是我觉得规模可控范围之内的企业级应用，并且数据价值极高的业务，比如典型的银行，他们还依旧会选择使用Oracle更加合适。 有财力养MySQL专家团队可以搞定一切 由于互联网的集中化部署和维护的特点，使得我们开发和运维团队的价值较高，因此大规模互联网公司有财力聘请专门的MySQL专家技术团队，这些专家可以把MySQL的使用、部署、运维、原理源码都搞得非常透彻，他们有能力搞定MySQL出现的一切问题

今天讲点关于我们公司技术架构演化历程，本人在公司还没正式成立的时候就来了，在此期间有幸经历并参与了公司技术架构的多次升级的改造工作，也很高兴能见证一个公司的发展历程，从中也学到了很多东西。好了废话不说了，开喷： 一、初始阶段 ：网站发展初期，我们的架构是什么样子的呢？下面用一张图还说明： 看着图来介绍下，我们初始阶段的网站技术架构，当然看着也不错了，开始阶段就用了这么多技术思想，感觉挺不错吧，用了反向代理、用了集群、用了分布式缓存、用了独立的文件服务器和独立的数据服务器，架构看起来貌似不错。但是随着用户访问量的增加，逐渐发现流量高峰期的时候我们的响应时间总是很慢，甚至有几次直接挂了，主要是访问数据库过于频繁，因为读写操作都是操作一个库，而我们只有一个库，之后呢，我们做了数据库读写分离，写请求走主库，读请求走读库，解决了数据库连接数不足的问题。 二、发展中期：网站发展中期，随着用户访问量的不断递增，我的技术架构发展成什么样子了呢？入下图所示： 随着流量的增大，发现读写分离已经不能满足我们的要求，写库，逐渐出现瓶颈，读库也因为越来越多的人操作，从而也开始变慢；然后我们开始升级我们的架构，先是按业务功能拆分代码，独立部署，然后抽出公共服务，做分布式部署，即所谓的soa服务化；因为服务化之后呢，不同业务使用不同的数据库，即所谓的垂直分库，后来呢 针对部分业务，我们又做了分库、分表技术

豆瓣网CTO洪强宁讲述网站架构变迁 罗马不是一天建成的，豆瓣的技术架构也是随着用户规模的增长一直在持续变化中。洪强宁，2002年毕业于清华大学，现任北京豆瓣互动科技有限公司首席架构师。洪强宁和他带领的技术团队致力于用技术改善人们的文化和生活品质，在网站架构、性能、可伸缩性上进行深入研究。豆瓣网曾获软件中国2006年度最佳技术应用网站。 校内网CTO黄晶讲述网站架构变迁 每个网站的发展都会按照一个大致相同的路线去完成，当然这里说的是每个相对成功的网站。 第一阶段： 这一阶段没有太大的访问量，甚至只有一台服务器就搞定了所有的访问。 DB 和前端的代码全都在一起，压力不高。忆者注：我觉得在 alexa 没进五万的时候，只要不是特殊的应用，基本都在此列吧。 第二阶段： 网站初具规模，DB压力大增，单独的一台DB已经满足不了现在的访问量，开始考虑读写分离的 Master-slave 库，使用三个及以上的服务器。忆者注：这时网站的alexa基本上会在1-3万的位置，每天的ip在5-10w的样子，当然，DB我们都认为是MySql。 第三阶段： 访问量继续增加，增加到了DB的压力在Master的机器上非常的明显了，Master开始出现吃不消的情况，出现写耗尽。主从也已经不能满足要求，需要进一步解决负载问题，此时要引入Mysql Proxy 程序，进行中间层代理，实现负载均衡，易于扩展。忆者注

这个架构基于squid、nginx和lvs等技术，从架构上对bbs进行全面优化和保护，有如下特点： 1、高性能：所有的点击基本上全部由前端缓存负责，提供最快速的处理。 2、高保障度：不需考虑应用程序稳定与否、程序语言是何种、数据库是何种，都能从架构上保证稳定。 3、高可用性：对应用程序的修改达到最简化：在程序的某些地方加入清缓存的语句即可，当然还需要做页面静态化的工作和统计工作。 首先看图，这个图比较大： 这个架构的特点和一些流程的说明： 1、主域名和图片域名分离 域名分离可以使流量分离，缓存策略分离等等，好处诸多。bbs初期一定要做好规划，将图片用另外的域名独立服务，即使没有足够机器，域名也要先分开。另外，图片服务器可以使用有别于主域名的另一个域名，一个好处是可以减少读取cookie对图片服务器的压力，另一个是提高安全性，避免cookie泄露。 2、使用LVS作为前端、二级代理和数据库的访问入口 使用LVS作为入口，比其他任何一种方式都来得更优质。首先LVS的负载能力很强，因为它工作在网络协议的第4层，使用虚拟ip技术，所以它本身并不担负任何流量的处理，仅仅是一个封包转发的功能；第二，LVS的配置相对简单而且稳定，一般去调整的几率比较低，也减少了因人为等因素而出现故障；第三，LVS可以处理任何端口的负载均衡，所以它基本可以做所有服务的负载均衡和容错。在这个架构中

先前一直用Visio，享受着它的各类强大、美观，但如果考虑到要跨平台…… 用软件搞设计我绝对是个“看脸色”的人，大名鼎鼎的Dia功能全面，使用人数众多，但那简陋的UI，复杂的操作让我望而生畏。好用免费开源跨平台的绘图工具实在太稀有了。好在还算是有这么一款：yEd http://www.yworks.com/en/products/yfiles/yed/ 怎么说呢，面子和功能上嘛，比上（Visio）不足，比下（Dia）有余，凑合着用呗，谁让我吝啬呢 :smirk: 不用废话了，看图吧，感觉还是可以的吧:stuck_out_tongue_winking_eye: 说一下它的几个不足： 没有时序图，没有！！ 解决方法是： http://yed.yworks.com/support/qa/602/support-for-sequence-diagrams-in-yed 下载来一看，my god,是一点点拼出来的……这有点扯了 不支持自由线条，它的线条必须有两个node来连接，鬼异的设计。 解决方法是画个矩形，设置高度是1:cry: 来源： oschina 链接： https://my.oschina.net/u/816048/blog/516010

基础理论 SOA 到 MSA 的进化 SOA 面向服务架构 由于业务发展到一定程度后，需要对服务进行解耦，进而把一个单一的大系统按逻辑拆分成不同的子系统，通过服务接口来通讯。面向服务的设计模式，最终需要总线集成服务，而且大部分时候还共享数据库，出现单点故障时会导致总线层面的故障，更进一步可能会把数据库拖垮，所以才有了更加独立的设计方案的出现。 MSA 微服务架构 微服务是真正意义上的独立服务，从服务入口到数据持久层，逻辑上都是独立隔离的，无需服务总线来接入，但同时也增加了整个分布式系统的搭建和管理难度，需要对服务进行编排和管理，所以伴随着微服务的兴起，微服务生态的整套技术栈也需要无缝接入，才能支撑起微服务的治理理念。 节点与网络 节点 传统的节点也就是一台单体的物理机，所有的服务都揉进去包括服务和数据库；随着虚拟化的发展，单台物理机往往可以分成多台虚拟机，实现资源利用的最大化，节点的概念也变成单台虚拟机上面服务；近几年容器技术逐渐成熟后，服务已经彻底容器化，也就是节点只是轻量级的容器服务。总体来说，节点就是能提供单位服务的逻辑计算资源的集合。 网络 分布式架构的根基就是网络，不管是局域网还是公网，没有网络就无法把计算机联合在一起工作，但是网络也带来了一系列的问题。网络消息的传播有先后，消息丢失和延迟是经常发生的事情，我们定义了三种网络工作模式： 同步网络 节点同步执行 消息延迟有限

微服务 & 微服务架构 微服务 不等于 微服务架构 微服务 : 强调的是服务的大小,它关注的是某一个点,是具体解决某一个问题\提供落地对应服务的一个服务应用,狭义的看,可以看做eclipse里面的一个个微服务工程/或者module.强调的是一个个的个体,每个个体完成一个具体的任务或者功能. 微服务架构是一种架构模式或者说是一种架构风格,它提倡将单一应用程序划分成一组小的服务,每个服务运行在其独立的自己的进程中.服务之间互相协调\相互配合,为用户提供最终价值.服务之间采用轻量级的通信机制相互沟通(通常是基于HTTP的RESTful API).每个服务都围绕着具体业务进行构建,并且能够被独立的部署到生产环境\类生产环境等.另外,应尽量避免统一的\集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言\工具对其进行构建,可以有一个非常轻量级的集中式管理来协调这些服务,可以使用不同的语言来编写服务,也可以使用不同的数据存储. 微服务的优缺点: 优点 1-每个服务足够内聚,足够小,代码容易理解这样能聚焦一个指定的业务功能或业务需求 2-开发简单\开发效率高,一个服务可能就是专一的只干一件事 3-微服务能够被小团队单独开发,这个小团队是2-5人的开发人员组成 4-微服务是松耦合的,是有功能意义的服务,无论是在开发阶段还是部署阶段都是独立的 5-微服务能够使用不同的语言开发

一、基础知识 1、分布式基础理论 1.1）、什么是分布式系统？ 《分布式系统原理与范型》定义： “分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统” 分布式系统（distributed system）是建立在网络之上的软件系统。 随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需 一个治理系统 确保架构有条不紊的演进。 1.2）、发展演变 单一应用架构 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。 适用于小型网站，小型管理系统，将所有功能都部署到一个功能里，简单易用。 缺点： 1、性能扩展比较难 2、协同开发问题 3、不利于升级维护 垂直应用架构 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。 通过切分业务来实现各个模块独立部署，降低了维护和部署的难度，团队各司其职更易管理，性能扩展也更方便，更有针对性。 缺点： 公用模块无法重复利用，开发性的浪费 分布式服务架构 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心

SpringCloud微服务应用入门 微服务架构概述 单体应用架构的不足 认识微服务架构 微服务架构的主要构成 搭建SpringCloud微服务应用 开发eureka服务器（即服务发现组件） 开发服务组件 开发zuul（网关组件） 案例源码地址 微服务架构概述 单体应用架构的不足 所谓单体应用是指一个归档文件（如war文件）包含所有功能的应用，是一种应用广泛的传统项目架构，这种架构具有结构简单，部署方便的优点，当项目的规模不是很大，使用范围和并发量也都不是太大时，生产运转是比较平稳和正常的。但是，近些年随着移动互联应用的发展，项目呈现出应用场景丰富‘，规模、使用范围和并发量较大，单体应用架构的不足之处也越来越明显，主要有以下几方面： 复杂度高、维护困难、不易扩展、部署风险大； 项目采用的技术体系早已确定，新技术难以引入； 可靠性不高，任何一个问题都可能导致整个应用崩溃； 对高并发缺乏良好的支持。 认识微服务架构 为了解决单体应用架构的不足和问题，人们提出了微服务架构，这种微服务架构的基本思想是将一个大的应用系拆分成许多足够简单的小规模应用，每一个小应用就是一个微服务，每个微服务都独立开发和部署，与其它微服务没有直接关系，甚至每一个微服务使用的技术可以是不相同的。 微服务架构一般具有易于开发维护和部署、技术使用不受限制、可伸缩性好、可以实现高可靠高并发部署、具有负载均衡能力。