标签：hsf 依赖库 多个 容量 目录 文件 分发 共享资源 延时
目录
架构的基本认识
架构的发展历程
单体架构
分布式（RPC）
面向服务架构（SOA）
微服务架构
架构当中的一些概念介绍（例如:服务治理）
架构的基本认识
定义 根据要解决的问题,对目标系统的边界进行界定,对目标系统按照某个原则进行切分,使拆分出来的部分进行有机的联系,合并组装称为一个整体,完成目标系统的所有工作
软件架构 有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计
核心目标 支持业务,技术解耦
主要手段 水平（横向分离） 垂直（纵向分离）
架构几个核心要素
1 高性能 提供快速的访问体验
2 可用性 保证服务器不宕机
3 伸缩性 通过硬件增加/减少,提高/降低处理能力
4 扩展性 方便的通过新增/移除方式,增加/减少新的功能/模块
5 安全性 提供网站访问和数据加密,安全存储等策略
架构的发展历程
单一应用架构
当网站流量很小时,只需要一个应用,将所有功能部署在一起,以减少部署节点和成本
用于简化增删改查工作流的数据访问框架（ORM）是关键
垂直应用架构
当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相关的几个应用
用户加速前端页面开发的WEB框架（MVC）是关键
分布式服务架构
当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的时长需求
用于提高业务复用及整合分布式服务框架（RPC）是关键
流动计算架构
当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率
用于提高机器利用率的资源调度和治理中心（SOA）是关键
为什么架构会一直变化（主要由于每种架构模式的缺点推进的）
1 单体式 在高并发的需求上,单体应用的缺陷是无法忍受的（改进:使用集群）
2 集群 把单体应用变成多体,变成集群,通过负载均衡分发服务请求不同的应用服务中（一定程度上解决了高并发问题） 但是如果要达到上万的并发级别,即便是强力增加节点数量,性能也不会提升很大,有其瓶颈
3 分布式 把系统安装模块划分为多个子系统,多个子系统之间需要进行通信,来共同完成业务流程
4 SOA 把工程都拆分成服务层工程,表现层工程,服务层中包含业务逻辑,只需要对外提供服务即可
单体架构
系统的所有功能单元,整体部署到同一进程（水平方向上,上下层制作划分清晰,但垂直方向上缺乏清晰的边界）
优点:
1 现有IDE都是集成开发环境,非常适合单体式应用,开发,编译,调试一站式搞定
2 一个应用包含所有功能,容易测试和部署
3 运行在一个物理节点,环境单一,运行稳定,故障恢复简单
缺点
1 业务边界模式,模式职责不清晰,当系统逐渐变大,代码依赖复杂,难以维护
2 所有人同时在一个工程上开发,容易发生代码修改冲突,依赖复杂导致项目协调苦难,并且局部修改影响不可知,需要全覆盖测试,需要重新部署,难以支持大团队并发开发
3 当系统很大时,编译和部署耗时
4 应用水平扩展难,一方面状态在应用内部管理,无法透明路由,另一方面,不同模块对资源需求差异大,当业务量增大是,一视同仁为所有模块增加机器导致硬件浪费
单体架构的发展历程
1 简单单体模式 代码层面没有拆分,所有业务逻辑都在一个项目里打包成一个二进制的编译后文件,通过这个文件进行部署,并提供业务能力
2 MVC模式 系统内的每个模块的功能组件按照不同的指针划分为模型,视图,控制器等角色,并以此来组织研发实现工作
3 前后端分离 将前后端代码耦合的设计改为前端逻辑和后端逻辑独立编写实现的处理模式
4 组件模式 系统的每一个模块拆分为一个子项目,每个模块独立编译打包成一个组件,然后所有需要的组件一起再部署到同一个容器里
5 类库模式 A系统复用B系统的某些功能,这时可以把B系统的某些组件作为依赖库,打包到A系统来使用
分布式（RPC）
本质 拆分+连接（整个系统的功能单元分散到不同的进程,然后由多个进程提供不同的业务能力）
分布式架构基本特点
1 分布式 多台计算机空间随意分布,同时,机器的分布情况也会随时变动
2 对等性 没有主/从之分,既没有控制整个系统的主机,也没有被控制的从机,组成分布式系统的所有节点都是对等的
3 并发性 并发地操作一些共享资源
4 缺乏全局时钟 一个典型的分布式系统是由一系列在空间上随意分布的多个进程组成的,具有明显的分布式,这些进程之间通过交换消息来相互通信,很难定义两个事件究竟谁先谁后
5 故障总会发生 组成分布式系统的所有计算机,都会有可能发生任何形式的故障
分布式基本问题
1 通信异常 网络本身的不可控性（硬件设备或系统不可用 节点通信延时）
2 网络分区 当网络由于发生异常情况,导致分布式系统中部分节点之间的网络延时不断增大,最终导致组成分布式系统的所有节点中,只有部分节点之间能够正常通行,而另一些则不能
3 三态（成功,失败,超时）
3.1 由于网络原因,该请求并没有成功地发送到接收方,而是在发送过程中就发生了消息丢失现象
3.2 该请求成功地被接收方接收后,并进行了处理,但是在响应反馈给发送方的过程中,发生了消息丢失现象
4 节点故障 组成分布式系统的服务器节点出现宕机或"僵死"现象
5 一致性问题 节点间通信是不可靠的,如何保证节点间的一致性（有状态的服务）
面向服务架构（SOA）
是一种设计方法,其中包含多个服务,服务之间通过相互依赖提供一系列的功能,一个服务通常以独立的形式存在于操作系统进程中,各个服务之间通过网络调用
微服务架构
是SOA上坐的升华,微服务架构强调的一个重点是"业务需要彻底的组件化和服务化",原有的单个业务系统会拆分为多个可以独立开发,设计,运行的小应用,这些小应用之间通过服务完成交互和集成
核心要素:服务的发现,注册,路由,熔断,降级,分布式配置
技术选型:通信协议,服务依赖模式,开发模式,运行模式
微服务主要的优势
1 降低复杂度 将原来耦合在一起的复杂业务拆分为单个服务,规避了原来复杂度无止境的积累,每一个微服务专注于单一功能,并通过定义良好的接口情绪表述服务边界,每个服务开发者只关注服务本身,通过使用缓存,DAL等各种技术手段来提升系统的性能,而对于消费方来说完全透明
2 可独立部署 每个微服务可以独立部署,当业务迭代时只需要发布相关服务的迭代即可,降低了测试的工作流同时也降低了服务发布的风险
3 容错 在微服务架构下,当某一组件发生故障时,故障会被隔离在单个服务中,通过限流,熔断等方式降低错误导致的危害,保证核心业务正常运行
4 可扩展
架构当中的一些概念介绍
服务治理介绍
背景:在服务治理之前,简单粗暴的RPC调用使用的点对点方式,完全通过人为进行配置操作决定,运维成本高（每次布置一套新的环境需要改一堆配置文件的IP）,还容易出错,且整个系统运行期间的服务稳定性也无法很好的感知
目的:是为了对整体的RPC调用进行集中化管理（减少重复难点,避免手动配置物理文件产生的问题,降低开发人员的技术运用成本）
成熟的解决方案: 阿里（dubbo,HSF） 腾讯（Tara） JSF CNCF 新浪（Motan） istio
包含内容
1 服务的自动发现 服务治理框架的基本功能（通过动态的感知到服务器的地址信息,然后针对该地址信息进行自动化配置模板化配置）（需要引进一个注册中心的概念来进行集中化管理）
2 客户端的自动发现 当我们在配置文件中指定具体的IP和端口来定义远程服务的地址,或者直接在程序里硬编码远程服务地址时,本身就是一个端到端的访问方式,无法灵活的在程序运行过程中去增加或减少后端的服务节点（需要和服务注册的实现方式配套,还可以针对不同类型的应用指定一些复制均衡的策略进行切换）
3 变更下发 客户端的自动发现就依赖于下发的数据,需要及时把提供服务的节点信息编号下发到各个客户端
场景:当我们进行一个发布的时候,先将需要发布的节点从负载均衡列表中移除,然后再进行更新,然后再添加到负载均衡列表中（避免了访问到正在发布中的程序）（基于状态监测模块去做）
标签：hsf 依赖库 多个 容量 目录 文件 分发 共享资源 延时
原文地址：https://www.cnblogs.com/hpzhu/p/10109736.html
