架构

软件架构就是在软件开发领域，实现软件系统目标的一个架构。当一个人新进入一个系统的时候，首先要摸清的就是这个系统的架构，从形式上去理解内容，从分析其部分到综合其整体。 一个软件系统是为了满足特定的功能需求。正如一个组织部门是为了完成一项事业。这都是在成事的层面。背后则是真正的推动力量必然是人， 是利益相关者。在政治上，是领袖，领袖的联盟成员即领袖的班底，各级官僚，老百姓等。在软件系统的利益相关者，用户客户，项目经理，开发、运维。甲方乙方各自是一个系统，又因为一个软件系统联结成为一个共同的系统。 为了解决特定问题，就需要对问题进行建模，模型就是人们在长期的解决问题过程中，形成的经验套路。为了能让甲方满意，就要找到甲方的关注点，即要需求分析，进而成为软件系统的关键约束，达成人之间的契约约束。 架构并不神秘。它是工程学，而非科学。在科学的世界里，对就是对，错就是错，容不得半点妥协；而在工程的领域里，妥协随处可见。所以没有完美的架构，只有合适的架构。两个差别很大的架构，当不给定context时，我们不能说架构A一定优于架构B。 很多软件工程师在一线开发岗位呆了十年八年，却未被贴上架构师的标签，只因为他们还没有找到属于自己的做架构的机会；而那些高高在上，张口闭口modularity，clean architecture，etc. 却一行代码不肯写也不肯读的所谓的『架构师』们

如果说架构的本质是管理复杂性，那么抽象、分层、分治和演化思维是我们工程师/架构师应对和管理复杂性的四种最基本武器。 1、抽象思维 抽象其实是这样定义的： 对某种事物进行简化表示或描述的过程，抽象让我们关注要素，隐藏额外细节。 在系统架构和设计中，抽象帮助我们从大处着眼（get our mind about big picture），隐藏细节（temporarily hide details）。抽象能力的强弱，直接决定我们所能解决问题的复杂性和规模大小。 软件系统架构设计和小朋友搭积木无本质差异，只是解决的问题域和规模不同罢了。架构师先要在大脑中形成抽象概念，然后是子模块分解，然后是依次实现子模块，最后将子模块拼装组合起来，形成最后系统。所以我常说编程和架构设计就是搭积木，优秀的架构师受职业习惯影响，眼睛里看到的世界都是模块化拼装组合式的。 2、分层思维 除了抽象，分层也是我们应对和管理复杂性的基本思维武器，如下图，为了构建一套复杂系统，我们把整个系统划分成若干个层次，每一层专注解决某个领域的问题，并向上提供服务。有些层次是纵向的，它贯穿所有其它层次，称为共享层。分层也可以认为是抽象的一种方式，将系统抽象分解成若干层次化的模块。 3、分治思维 分而治之(divide and combine或者split and merge)也是应对和管理复杂性的一般性方法，下图展示一个分治的思维流程

软件架构师的架构流程 架构的定义：一个程序和计算系统是指系统的一个或多个结构。结构中包括软件的构建，构建的外部可见属性以及它们之间的相互关系。 软件架构师能够通过软件架构分析设计在满足规定需求方面的有效性、在设计变更相对容易的阶段，考虑体系结构可能的选择方案、降低与软件构造相关联的风险。 软件架构的优点：软件架构能够满足系统的品质、架构设计使受益人达成一致的目标、架构设计能够支持计划编制过程、架构对系统开发的指导性。架构设计为复用奠定了基础、架构设计能够降低维护费用、架构设计能够支持冲突分析。一个好的架构是高内聚、低耦合的，既可以作为一个完整的可交付模块，也可以“打碎”了重组； 一般的软件开发过程包括五个阶段：概念化阶段、架构设计阶段、并行发与测试阶段、验收与测试阶段。但这是项目经理、架构师、开发人员、测试人员等所有人公同遵守的过程，对于软件架构师的架构设计及开展非常依赖其上游活动，这些上游活动包括需求分析和领域建模。需求分析，在没有全面认识需求并权衡不同需求之间相互影响的情况下，设计出的架构很有可能有问题。领域建模，领域建模的目的是透过问题领域的重重现象，捕捉其背后最为稳固的领域概念及这些概念之间的关系。概念性架构的设计过程：确定对架构的关键的需求。对功能需求进行筛选，对非功能需求进行综合权衡，最终确定对软件架构起关键作用的需求子集。 概念性构架设计：分析关键用例的用例规约

数据中心网络 数据中心网络是企业IT创建私有云和混合云架构战略中的关键组成部分，它能够改进数据中心的网络的自动化、敏捷性、安全性和分析能力，能够实现企业自有应用程序与公共云服务的无缝集成。随着时间的推移，前沿软件将会逐渐向基于意图的数据中心网络转变，以实现全面自动化和快速修复应用性能问题。 随着云计算的发展，计算资源被池化，为了使得计算资源可以任意分配，需要一个大二层的网络架构。即整个数据中心网络都是一个L2广播域，这样，服务器可以在任意地点创建，迁移，而不需要对IP地址或者默认网关做修改。大二层网络架构，L2/L3分界在核心交换机，核心交换机以下，也就是整个数据中心，是L2网络（当然，可以包含多个VLAN，VLAN之间通过核心交换机做路由进行连通）。大二层网络架构虽然使得虚机网络能够灵活创建，但是带来的问题也是明显的。共享的L2广播域带来的BUM（Broadcast·，Unknown Unicast，Multicast）风暴随着网络规模的增加而明显增加，最终将影响正常的网络流量。 数据中心内部的流量，也就是东西向流量，这与上面的技术发展对网络架构的影响分析相符，这也是为什么东西向流量尤其重要。 来源： CSDN 作者： _BOTAK_ 链接： https://blog.csdn.net/BOTAK_/article/details/103754027

1.SOA架构和微服务架构的区别 首先SOA和微服务架构一个层面的东西，而对于ESB和微服务网关是一个层面的东西，一个谈到是架构风格和方法，一个谈的是实现工具或组件。 1.SOA（Service Oriented Architecture）“面向服务的架构”:他是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在于操作系统进程中。各个服务之间 通过网络调用。 2.微服务架构:其实和 SOA 架构类似，微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。 微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想 2.ESB和微服务API网关。 1.ESB（企业服务总线），简单 来说 ESB 就是一根管道，用来连接各个服务节点。为了集 成不同系统，不同协议的服务，ESB 做了消息的转化解释和路由工作，让不同的服务互联互通； 2.API网关:API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存

内容目录： 1.软件开发架构 2.OSI七层协议 3.每层协议介绍 1.软件开发架构 c/s架构： c：客户端 s：服务端 b/s架构： b:浏览器 s:服务器 本质:b/s其实也是c/s 2.OSI七层协议 3.各层介绍 3.1 物理层 规定计算机之间物理连接方式，传输的数据都是 0,1 二进制的电信号 3.2 数据链路层("以太网协议"！) 1.规定了二进制数据的分组方式 2.规定了只要是接入物联网的计算机，都必须有一块网卡！ 网卡上面刻有世界唯一的编号: 每块网卡出厂时都被烧制上一个世界唯一的mac地址， 长度为48位2进制，通常由12位16进制数表示（前六位是厂商编号，后六位是流水线号） 管网卡上刻有的编号叫电脑的mac地址 ----->上面的两个规定其实就是 "以太网协议"！ 基于以太网协议通信：通信基本靠吼（一对多广播形式） 弊端:容易产生广播风暴 交换机：如果没有交换机，你的电脑就变成了马蜂窝，有了交换机之后， 所有的电脑只需要有一个网卡连接交换机，即可实现多台电脑之间物理连接 3.3 网络层(IP协议) 规定了计算机都必须有一个ip地址 ip地址特点:点分十进制 有两个版本ipv4和ipv6 为了能够兼容更多的计算机 最小:0.0.0.0 最大:255.255.255.255 IP协议可以跨局域网传输 ip地址能够唯一标识互联网中独一无二的一台机器！ 3.4 传输层

单体应用架构 从单体应用架构发展到SOA架构，再到微服务架构，应用架构经历了多年的不断演进。 初生 ​ 在Web应用程序发展的早期，大部分的Web工程是将所有的功能模块打包到一起部署和运行。 在单体应用中，所有这些模块都集成在一起，这样的系统架构就叫做单体应用架构。 单体应用是最早的应用形态，开发和部署都很简单。 典型的技术是LAMP，即Linux、Apache、Mysql、PHP，但是PHP的性能并不是很好，随着网站业务的发展，越来越多的用户访问，这种架构的性能越来越差，越来越多的数据导致储存空间不足。这时候该怎么办呢？将应用服务与数据服务分离。 应用服务与数据服务分离 在扩展的过程中，应用服务器需要更快更强大的CPU（处理大量的业务逻辑），数据库服务器需要更快的硬盘和更大的内存（快速磁盘检索和数据缓存），文件服务器需要更大的硬盘（存储大量用户上传的文件）。 不同的服务器承担不同的服务角色，提高了并发处理能力，扩大了数据存储空间，整个系统的性能会有较大提升。 可是随着用户增多，网站再次面临挑战。数据库压力太大导致访问延迟，进而影响整个网站的性能，用户体验感极差！这时候该怎么办呢？使用缓存提高性能。 使用缓存改善性能 使用本地缓存速度会极快，但是空间有限，使用远程分布式缓存速度稍慢（相对本地缓存来说稍慢，但也很快了），但是可以按需扩展。常用的缓存组件是Redis、Memcache。

本文转载自： 什么是分布式微服务架构？三分钟彻底弄懂什么是分布式和微服务 一、微服务简介 1. 微服务的诞生 微服务是基于分而治之的思想演化出来的。过去传统的一个大型而又全面的系统，随着互联网的发展已经很难满足市场对技术的需求，于是我们从单独架构发展到分布式架构，又从分布式架构发展到 SOA 架构，服务不断的被拆分和分解，粒度也越来越小，直到微服务架构的诞生。 微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。 每个服务运行在其独立的进程中，服务和服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。 2. 微服务架构与SOA架构的区别 微服务是真正的分布式的、去中心化的。把所有的“思考”逻辑包括路由、消息解析等放在服务内部，去掉一个大一统的 ESB，服务间轻通信，是比 SOA 更彻底的拆分。 微服务架构强调的重点是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用，这些小应用之间通过服务完成交互和集成。 3. 微服务架构引发的问题

一.软件开发架构 　　1.c/s架构 　　　c:客户端 　　　s:服务端 　　2.b/s架构 　　　b:浏览器 　　　c:服务器 　　手机端:好像C/S架构比较火,其实不然,微信小程序、支付宝第三方接口 　　B/S架构的优点是统一接口 　　PC端:B/S架构比较火 　　本质:B/S其实也是C/S 　　服务端:24小时不间断提供服务,谁来我就服务谁。 　　客户端:想体验服务的时候,就去找服务端体验服务 二.网络编程介绍 　　1.学习网络编程 -->>> 可以开发C/S架构的软件 　　　并发编程、前端、数据库、框架 -->>> 可以开发B/S架构的软件 　　　网络编程起源于美国军事，主要是实现远程数据的传输 　　2.如何实现远程通信 　　　第一个需要具备的条件就是:物理连接介质 　　　第二计算机与计算机想要实现远程通信,还需要一个共同的标准---协议 　　3.OSI七层协议(模型) 　　　OSI七层协议 我们只需要了解五层 　　　　应用层-------------> 　　　　表示层-------------> 应用层 　　　　会话层-------------> 　　　　传输层-------------> 传输层 　　　　网络层-------------> 网络层 　　　　数据链路层---------> 数据链路层 　　　　物理连接层---------> 物理连接层 三.OSI协议解析

原 生 云 术语原生云已成为一种越来越流行的简化方式，用于谈论利用云，容器和编排的现代应用程序和服务，通常基于开源软件。实际上，云计算本地计算基金会（CNCF）成立于2015年，用他们的话说，“围绕一系列高质量项目建立社区，这些项目将容器作为微服务架构的一部分进行编排。” 作为Linux Foundation的一部分，CNCF旨在将开发人员，最终用户和供应商（包括主要的公共云提供商）聚集在一起。 CNCF旗下最着名的项目是Kubernetes本身，但该基金会还孵化和推广云原生态系统的其他关键组件：普罗米修斯，特使，头盔，流利，gRPC等等。 那么云本地人究竟是什么意思呢？像大多数这样的事情，它对不同的人意味着不同的东西，但也许有一些共同点。 原生云应用程序在云中运行;这没有争议。但是，仅仅使用现有应用程序并在云计算实例上运行它并不会使其成为原生云。它既不是在容器中运行，也不是使用Azure的Cosmos DB或Google的Pub / Sub等云服务，尽管这些可能是原生云应用程序的重要方面。让我们来看看大多数人都同意的云原生系统的一些特征： 自动化 如果应用程序要由机器而不是人工来部署和管理，则需要遵守通用标准，格式和接口。 Kubernetes提供这些标准接口的方式意味着应用程序开发人员甚至不需要担心它们。 无处不在，灵活多变，因为它们与磁盘等物理资源分离