什么是架构
架构又称软件架构，是有关软件整体结构与组件的抽象描述，可以简单理解为软件设计和开发的方法论。架构在方法选择上起至关重要的指导作用。架构就像大厦的地基，地基合理坚实，上层才能良好发展，给项目带来收益
几种典型架构
单机架构
单机架构就是把所有功能都实现在一个进程中，并部署在一台机器上。
单机架构的优点是非常简单，缺点是会遇到并发处理的难题，而且运维需要停服。
C10k problem
这里老师提到了C10k problem这个名词。这里的C是Client的缩写，而10K就是10000数量的意思。C10K问题关注的是单机如何处理1万个并发连接的问题，最早由Dan Kegel于1999年在其个人站点提出：www.kegel.com/c10k.html 。
当时计算机软硬件性能比较基础，这个问题引起人们对网络套接字优化和服务端调度的关注，这个词语也随着时代的发展逐渐变化，如C10M代表的是处理1000万个并发连接。现在的计算机已经有足够的性能和优秀的软件来支撑单机数百万连接了，然而并发问题仍然是后端架构设计中不能略过的关键问题。
单体架构
单体架构是对单机架构的改进。既然单机处理能力有限，就可以采用分布式部署的模式设置多台单机，再设置一个分流环节，将请求转发给各个单体服务器来处理。
单体架构的优点是可以实现水平扩容，处理能力不够时只需要简单添加新的单机即可；运维不需要停服，可以逐个对单机维护不影响其他单机的运行。单体架构下，每台机器的功能是一致的，因此它没有解决这两个缺点：
- 职责太多，开发效率低：每台机器都要实现系统的完整功能，不能专注于某个功能的开发。
- 爆炸半径大： 爆炸半径是指爆炸可能造成损害的区域范围。在生产环境中指的就是部署的服务故障时可能影响的软件功能范围。单体架构下每一个单机下线，都会造成所有功能的处理承载量下降，因此爆炸半径覆盖了软件多数功能。
垂直应用架构
为了解决单体架构的问题，垂直应用架构提供了一种思路，将系统按照服务拆分任务，分配给不同的服务器，从而实现职责的简单划分，一定程度上提高开发和运维的效率。不过在实践中一个服务往往是大量功能点的集合，仍然存在功能琐碎的问题
SOA、微服务架构
SOA（Service-Oriented Architecture）架构具有两个特性：
- 将应用的不同功能单元抽象为服务，从而细分职责
- 定义服务之间的通信标准，确保服务之间的数据流通
微服务架构则是SOA架构去中心化的演进方向，旨在减少服务之间的沟通消耗，避免SOA服务内部集中沟通导致的过度中心化问题，他实现了水平切分，减少了跨级别调用链，让每个服务直接负责的上下级减少。
这类架构在解决之前的弊端时，也会引入新的问题：
- 数据一致性问题：不同服务如何确保数据同步
- 高可用问题：服务之间如何进行可靠合作
- 治理问题：一个服务出现问题时，要如何容灾
- 解耦和过微问题：过度细分会导致运维成本提高，要如何权衡？
架构的演化
随着需求量的逐渐增大，必然要增加处理单元。
随着功能越来越复杂，势必要用分工合作的思路。
架构的演进是伴随着软件的体量的增长的，适时对软件进行垂直切分和水平切分，将对软件开发和运维产生良好效益。
企业级后端架构剖析
云计算技术
云计算是指通过软件自动化管理，提供计算资源的服务网络，是现在互联网大规模数据分析和存储的基石。
云计算的基础是虚拟化技术和编排方式，关系到资源的分配和调度。
云计算提供一系列特有的架构：
- 基础设施即服务IaaS（Infrastructure as a Service）：服务商提供互联网基础设施，比如用户只需要获得服务器、云硬盘、宽带网络，而不用关心物理的机房、数据中心、网络怎么建设。但是，用户需要自己进行服务器系统安装、环境部署和软件配置。
- 平台即服务PaaS（Platform as a Service）：服务商提供底层软件设施，比如为用户准备安装了指定操作系统、数据库软件、环境套件的主机。用户需要自己控制上层应用的部署和托管。
- 软件即服务Saas（Software as a Service）：服务商及提供基于软件的解决方案来满足客户的需求，比如用户想要一套OA办公系统，CMS内容管理系统，HRM人事管理系统等，而不用自行搭建和维护这样的服务，能够简化用户的工作。
- 函数即服务FaaS（Function as a service）：服务商提供一个平台，允许客户开发、运行和管理应用程序功能，而不用关心如何启动和部署这样的程序。这个模式是“无服务器”体系架构的方式，具有灵活性，适合构建微服务应用程序。
云原生技术
云原生技术为公司在公有云、私有云、混合云等新型动态环境中，构建和运行可弹性拓展的应用提供了可能。
云原生为公司提供了以下关键能力：
弹性资源调度
弹性计算资源
- 服务资源调度：分配微服务、大服务使用的资源。
- 计算资源调度：分配在线计算、离线计算使用的资源
- 消息队列：和计算资源调度类似，提供海量的数据吞吐和大数据分析能力。
弹性存储资源
云原生让用户可以将存储资源看作服务，寻找对应的服务来满足自己的存储需求。
- 经典存储：对象存储、大数据记录存储。
- 关系型数据库：业务记录存储。
- 元数据：提供服务发现能力
- NoSQL：key-value存储，实现缓存和分布式事务。
DevOps
DevOps贯穿整个软件开发周期，使用一系列自动化流程，提高软件开发、交付的效率。DevOps提供了敏捷开发、持续集成/交付（CI/CD）的能力。
微服务架构
微服务架构实现业务功能单元的解耦，同时提供一套统一的通信标准确保服务之间的数据流通。
微服务常见的通信标准是HTTP（RESTful API）和RPC（Thrift, gRPC），需要结合性能、服务治理、协议可解释性来选择。实际场景下，常常使用微服务框架提供的通信能力，而不用自己从头实现一套。
服务网格
服务网格实现业务与治理的结构以及异构系统治理的统一化，从而提供复杂的治理能力。
企业级后端架构的挑战
实际部署中，云平台海量的资源和物理设施有限的资源是相悖的，引出以下两方面的问题：
基础设施层面：
- 物理资源是有限的：机器、带宽
- 资源利用率受制于部署服务
用户层面：
- 网络通信开销较大
- 网络抖动导致运维成本升高
- 异构环境下，不同实例水位不均
优化方式
离在线资源并池
在线业务以IO密集型为主，要求计算的实时性，但是具有潮汐性，不同时间段的压力不同。离线业务以计算密集型为主，对计算实时性不高。
把在线和离线资源放入同一个资源池进行调度，利用在线业务的潮汐性自动扩缩容，能够有效降低物理资源成本，提供更多的弹性资源，增加收益。
亲和性部署
如果两个微服务之间通信密切，则这两个服务的亲和性较高。将满足亲和性条件的容器调度到一台宿主机，让微服务中间件与服务网格通过共享内存通信，能够有效降低通信成本，提高服务可用性。
流量治理
基于微服务中间件和服务网格的流量治理，赋予微服务熔断、重试的能力，提供复杂环境下的流量调度，可以提高微服务调用容错性，增强容灾能力，还能进一步提高开发效率。
CPU水位负载均衡
结合IaaS提供的资源探针和服务网格的负载均衡能力，能够为自动扩缩容提供反馈，打平异构环境下算力的差异。
尾声
软件架构应该根据软件体量来合理制定，同时随着软件体量的成长动态变化。做好架构设计，可以参考以下四点：
- 需求先行：弄清楚要解决什么问题
- 业界调研：业界都有哪些解决方案可控参考
- 技术选型：内部/社区都有哪些基础组件
- 异常情况：考虑清楚故障发生的影响和对策
最后，没有最好的架构，只有最适合的架构。
