架构

一、单体架构 1.单体架构 单体架构也被称为单体系统或者是单体应用，就是一种系统中所有的功能、模块耦合在一个应用中的架构方式。用简单的方式理解就是将整个应用包括应用、数据库等都在同一个服务器上。而分布式从简单的角度上理解就是将应用和数据等分开到不同的服务器上，就然后对于应用和数据库进行不同方向上的性能优化等等操作。 2.单体架构特点 打包成一个独立的单元（导入称为一个jar包或者是一个war包）部署完成应用之后，应用通过一个进程的方式来运行 单体架构的优缺点 优点 项目易于管理 部署简单 缺点 测试成本高 可伸缩性差 可靠性差 迭代困难 跨语言程度差 团队协作难 二、微服务架构 1.什么是微服务 微服务是一种架构风格，一个大型的复杂软件应用，由一个或者多个微服务组成，系统中的各个微服务可以被独立部署，各个微服务之间是松耦合的，每个微服务仅仅关注于完成一件任务并很好的完成该任务。将一个复杂的软件系统，进行了惨无人道的拆分，但是通过拆分之后，这个复杂的应用系统变的更加的高效。 2.架构风格 所谓的架构风格就是项目的一种设计模式。而我们常见的程序设计模式有以下的四种方式。后面对于每个模式的优缺点进行了详细的比较。 常见的架构风格 客户端与服务器端 ：包括C/S 和B/S两种，而B/S比较特殊。 基于组件模型的架构（EJB） 分层架构（MVC） 面向服务架构（SOA） 3.微服务特点 （1

系统架构遵循的三大原则 提升用户体验：提升用户体验，减少用户流失 提高敏捷性：及时响应业务需求，促进企业发展 降低成本：降低增加产品、客户或业务方案的成本 传统单体架构 先来看看传统单体项目架构图 从单体应用架构图得出如下结论： 传统的单体应用架构功能集中，代码和数据中心化，一个发布包部署后运行在同一个进程中的应用程序。 复杂性高：由于是单个归档文件，所以整个项目文件包含的模块非常多，导致模块的边界模糊、依赖关系不清晰、代码的质量参差不齐，混乱的堆在一起，使得整个项目非常复杂。以致每次修改代码，都非常小心，可能添加一个简单的功能，或者修改一个Bug都会带来隐藏的缺陷。 技术债务：随着时间的推移、需求的变更和技术人员的更替，会逐渐形成应用程序的技术债务，并且越积越多。 扩展能力受限：单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。 微服务架构 再来看看微服务架构图 从微服务架构图得出如下结论： 微服务把每一个职责单一的功能放在一个独立的服务中 。 每个服务有多个实例在运行，每个实例可以运行在容器化平台内，达到平滑伸缩的效 果，单个微服务启动较快。 每个服务应该有自己的运营平台，以及独享的运营人员，这包括技术运维和业务运营人 员：每个服务都高度自治，内部的变化对外透明。 易于开发和维护：一个微服务只会关注一个特定的业务功能，所以业务清晰、代码量较少

SOA架构 SOA是一种面向服务的体系结构，是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。 SOA架构中有两个主要角色：服务提供者（Provider）和服务使用者（Consumer）。而软件代理则可以扮演这两个角色。该Consumer层是用户（人、应用程序或第三方的其它组件）与SOA交互的点，和Provider层则由SOA架构内的所有服务所构成。 虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经不符合业务开发时“高内聚，低耦合”的要求。虽然基于 SOA 的系统并不是完全的排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。不同之处在于接口本身。SOA 系统原型的一个典型例子是通用对象请求代理体系结构（Common Object Request Broker Architecture，CORBA），它已经出现很长时间了，其定义的概念与 SOA 相似。 微服务架构 其实和 SOA 架构类似,微服务是在

一、架构 两种常见的架构： C/S架构 (客户机/服务器)和 B/S架构 (浏览器/服务器，也属于C/S架构的一种)。 　　 C/S架构优点： 能充分发挥客户机的性能 由于只有一层交互，因此响应速度较快，安全性高 　　 C/S架构缺点： 用户群固定,需要下载客户端才能使用 维护成本高 　　B/S架构优点： 客户端无需安装，有浏览器就行，跨平台 B/S架构可以直接放在广域网上，通过一定的权限控制实现多客户访问的目的，交互性较强 统一了应用的接口 　　 B/S架构缺点： 跨浏览器问题 在速度和安全性上需要花费巨大的设计成本 二、通信 网络编程基本上都是基于请求/响应方式的，即一个设备发送请求数据给另外一个，然后接收另一个设备的反馈。 　　MAC地址：物理地址，由网卡决定的，是固定且唯一的。在OSI模型中第二层数据链路层负责。 　　IP地址：四位点分十进制，在计算机内部存储时只需要4个字节即可。在OSI模型中第三层网络层负责。标识了计算机在网络中的位置。 可以使用IP或域名来标识网络上的一台设备 。 　　域名：由于IP地址不方便记忆，给IP取一个字符的名字，IP和域名之间存在一定的对应关系。在网络中只能使用IP地址进行数据传输，所以在传输以前，需要把域名转换为IP，这个由DNS的服务器完成。 　　端口：规定一个设备有2 16 个，即65536个端口，每个端口对应一个唯一的程序

针对上一个版本https://my.oschina.net/shyloveliyi/blog/786337，有如下更新： 1、解决数据采集汇总后实时存储到hive表中。 2、升级storm为jstrom。 架构图、流程图不变，在网络拓扑图增加一个hbase集群节点，数据汇总后采集到hbase中，然后hive建立hbase映射表以及storm节点修改为jstorm节点。 新的网络拓扑图如下： 来源： oschina 链接： https://my.oschina.net/u/2358114/blog/788213

概念 “4+1”视图，是指从5个不同视角来描述软件体系结构。 “4+1”分别指： 逻辑视图 过程视图 物理视图 开发视图 场景/用例 视图 逻辑架构的描述可以围绕前四个视图进行组织，然后结合用例或场景进行说明，形成第五个视图。 每个视图只关心系统的一个侧面，5个视图结合起来，才能反映系统的全部内容。 关于视图 软件设计可以从不同的概念角度进行描述和记录，这些角度通常被称为视图。 “视图表示软件体系结构的一部分，它显示软件系统的特定属性” 不同的视图涉及与软件相关的不同问题。 总之，软件设计是由设计过程产生的多方面的产物，通常由相对独立的正交视图组成，可以结合建筑视图理解。 逻辑视图 当使用面向对象的设计方法时，逻辑视图对应设计的对象模型，常用描述方法有UML类图、E-R图。 逻辑架构主要支持功能需求，即系统应该为用户提供什么样的服务。 系统被分解成一组关键抽象，以对象或对象类的形式从问题中表述。 类的设计遵循抽象、封装和继承的原则，这种分解不仅是为了进行功能分析，也是为了理清系统各个部分的通用机制和设计元素。 过程视图 过程架构关注设计的并发和同步方面，考虑了一些非功能性需求，比如性能和可用性。 过程视图可以在几个抽象层次上进行描述，每个抽象层次处理不同的关注点： 在最高层次上关注进程，进程分布在由LAN或WAN连接的一组硬件资源上，作为一组独立执行的通信程序逻辑网络。

十二年前，为了解决支付宝第一代架构在迅猛发展的业务面前捉襟见肘的困境，蚂蚁金服技术团队开启了一次前所未有的尝试。创新都是被逼出来的，今天高速发展的SOFAStack同样如此。 十二年时间，几代蚂蚁技术人参与攻坚，SOFA走出了一条跟传统金融行业不同的分布式架构之路。这条路，既要基于不可靠的硬件系统实现金融级的性能和可靠性，又要应对支付宝这样的超大规模互联网金融应用，很不容易，但蚂蚁技术团队做到了。今天，就让我们聊聊SOFAStack的前世今生。 SOFA缘起 2006年，支付宝面临的最大问题是业务变得越发复杂，工程师数量也越来越多，原来的单体系统逐渐无法装载更多更复杂的业务逻辑，也不能让大量工程师一起并行工作。当时的支付宝希望，系统可以做到成百上千个项目并行进行，并且每个工程师可以不受干扰地工作，当业务逻辑增加的时候，系统的复杂度不至于指数级上升。技术团队要做对未来的技术架构做一个选择。 支付宝团队做了一个决定，要走一条过去没有人走过的路，启动了支付宝技术系统的服务化之路，也是支付宝第二代架构的由来。2007年开始，支付宝启动了对交易系统、商户系统、会员系统、支付清算系统的改造。 当时担任支付宝首席架构师的程立，给要做的这套分布式架构起了一个“SOFA”的名字，其背后有两个含义：一是按照当时的技术趋势，要做面向服务的架构，即Service Oriented Architecture

#何为大型网站# ##大型网站特性## 既然说的是大型网站架构，那么 架构的背后自然是解决人因面对大型网站特性而带来的问题 。这样可以先给大家说下大型网站的特性， 这些特性带来的问题就是人要解决的问题 ： 高并发、大流量：PV 量巨大； 高可用：7*24 小时不间断服务； 海量数据：文件数目分分钟 xxTB； 用户分布广泛，网络情况复杂：网络运营商； 安全环境恶劣：黑客的攻击； 需求快速变更，发布频繁：快速适应市场，满足用户需求； 渐进式发展：慢慢地运营出大型网站； ##大型网站目标## 既然说到了大型网站的特性，那么**解决这些特性带来的问题要达到什么目标呢？**如下： 每个目标背后面临着技术、设计、维护等诸多方面的挑战； 而目标本身的期望值也会根据实际情况进行调整，这也意味着网站架构建设是个不断调整的过程。 有了问题，也定了伟大的目标，那么网站在不同阶段面对不同的问题，是如何解决的？又是如何一步步成长为大型网站架构，实现这些伟大的目标呢？ ##如何网站架构## 首先，什么是大型网站架构呢？ 其实大型网站架构的概念对于每一个开发者来说很笼统、很模糊，正如盲人摸象，看到的、了解到的只是很小的一部分，大部分情况下我们只是负责架构中的一小块内容，所以很难清晰地给出具体定义。这就是所谓“不识庐山真面目 只缘身在此山中”的尴尬吧。所以我们要跳出来，站在宏观的角度

https://www.cnblogs.com/jsjwk/p/11015666.html 来源： https://www.cnblogs.com/cuiqq/p/11882160.html

驱动相关：硬件之上的软件层，负责底层硬件与用户程序的交互 设备相关：底层设备的硬件操作 总线：匹配设备和驱动 设备驱动分层的思想：为同一类设备设计一个框架，而框架中的核心层则实现了该设备的一些通用功能。 来源： https://www.cnblogs.com/lilto/p/11878320.html