软件架构

3 月，跳不动了？>>> 浅谈软件架构 ( 一 ) 这个世界上，被人们创造出来的软件架构大概已经有几百种之多了。当然，它们所处的层次，以及应用范围是不同的。本文讨论的是，工作在协议顶层——即应用层，且是机器间联网工作的软件架构。（由于内容荣杂，本文将分多个期次介绍，请读者关注后续博文） 开篇 行文将讨论的软件架构为以下 7 类： 1. C/S 2. B/S 3. Cluster (HA) 4. Cloud 5. Distributed 6. APNS-like 7. P2P 一， C/S 架构。 这个词汇可谓老生常谈了。自高级语言编程在网络应用中一出现就随之诞生了。本文作者也在别的博文中讨论过，请读者参考另一篇博文《 CS 架构与多进程多线程》。（此处附图一张） 二， B/S 架构。 如今的互联网世界，几乎被 B/S 架构垄断。诸如博客，社交，电商等等都基于 B/S 搭建。它存在与世界已经三十多年了，从上世纪九十年代开始流行至今，且应用增长速度长期处于暴增状态。就是如今的手机客户端也大多是 B/S 的功能复制品或是 http 协议的封装体。可以这么说， B/S 就是人们日常离不开的互联网的核心。 接下来，我们从发展历史，以及应用两个方面来叙虽说 B/S 的传奇故事。 1. 发展历史 众所周知， B/S 架构指的是浏览器（ Browser ） / 服务器（ Server ）的工作模型

#第三章 大型网站核心架构要素 软件架构：有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计 软件架构需要关注的几个方面： 系统功能需求（最基本的） 性能 可用性 伸缩性 扩展性 安全性 ##3.1 性能 ##3.2 可用性 对于大型知名网站，可用性要达到99.99%。 网站高可用架构的前提是：必然会出现服务器宕机，而高可用设计的目标就是当服务器宕机的时候，服务或应用依然可用。 高可用的主要手段是 冗余 ，应用部署到多台服务器上同时提供访问，数据存储到多台服务器上互相备份。 其他：软件开发过程保证质量，自动化测试，自动化发布，灰度发布等。 如何衡量一个系统架构设计是否满足高可用的目标？ 就是假设系统中任何一台或多台服务器宕机时，已经出现各种不可预期的问题时，系统整体是否依然可用。 3.3 伸缩性 伸缩性：通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。 衡量伸缩性的主要指标：是否可以用多台服务器构建集群，是否容易向集群中添加新的服务器。加入新的服务器之后是否可以提供和原来的服务器无差别的服务。集群中可容纳的总的服务器数量是否有限制。 对于 应用服务器集群 ，只要服务器上不存数据，所有服务器都是对等的，通过使用合适的负载均衡设备就可以向集群中不断加入服务器。 对于 缓存服务器集群 ，新加入的服务器会导致缓存路由失效