DevOps中的软件架构与微服务

DevOps在需求阶段就要考虑运维的问题，运维的需求要如何反应在架构中，所以软件架构也是DevOps需要关注的一个重要部分。

一、关于软件架构

软件架构是对软件整体结构与组件的抽象描述，用于指导软件系统的设计、开发、部署、运维和使用。关于软件架构的定义，有2个比较官方的说法：

1、软件架构是“系统在其环境中的最高层概念”（IEEE定义）

2、软件架构是“一种由软件基本元素以及外部可见的属性和它们直接的关系构成的一种结构”（卡耐基梅隆大学软件研究所SEI 定义）

架构的目标来源于需求，软件架构必须要能够反应应用的功能性需求、非功能性需求（性能、稳定性、可靠性、可维护性等），及如何部署和开发等。

二、软件架构的模型

软件架构从不同的关注点（视角）看，有不同的视图，通常有5种架构模型：

1、逻辑视图

反应功能性需求，即系统提供哪些功能或服务。

2、开发视图

软件需要开发哪些模块（子系统、程序库等），及如何组织。

3、进程视图

从性能、可用性等非功能需求的角度描述的系统。强调系统的并发、分布、完整性和容错性，以及把逻辑视图中的抽象元素放到进程试图中时，哪个控制线程去运行一个操作。

4、物理视图（部署视图）

把进程视图的进程映射到一组基于网络的计算节点上，主要考虑非功能需求，如可用性、可靠性（容错性）、性能（吞吐量）及横向扩展性等。

5、场景视图

利用对象场景图和对象交互图，描述系统中一些重要用例的场景，对最重要的一些需求进行抽象。

三、软件架构的发展与演进

软件架构随着软件系统的功能和非功能需求的变化，需要不断的发展和演进。特别是随着用户数量（并发量）、数据量、流量及系统复杂性的激增，如何在有限的资源下更好的运行、维护系统，保证系统的可用性，是软件架构面临的挑战。

随着软件应用及技术的发展，软件架构演进经历了单体架构、分层架构、SOA架构、分布式架构几个阶段的发展。

单体架构的应用软件的全部功能被打包在一起，部署在同一个JVM或同一台机器上。

分层架构也叫N层架构，根据应用的功能分为多层，通常包括展示层、业务层、持久层、数据库层，有时候还有一个服务层，每一层都有着特定的角色和职能，每一层中的组件只会处理本层的逻辑。

SOA架构（面向服务的体系结构）是构造分布式计算的应用程序的方法，它将应用程序的功能作为服务发送给最终用户或者其他服务。SOA架构中一般会涉及企业消息总线（ESB）和服务编排（Service Orchestration）。SOA架构是在企业需要把许多系统集中到一起工作的实践中演化而来的，每个系统都是高内聚的，对外以暴露接口的方式提供服务。SOA架构强调系统服务化和系统之间用良好定义的接口进行交互。

在流量爆炸的互联网时代，无论从开发角度、性能角度，还是维护角度，单体架构都无法满足互联网软件系统的进一步扩展，需要真正的分布式架构。分布式系统是建立在网络之上的软件系统，系统具有高度的内聚性和透明性。核心理念是让多台服务器协同工作，完成高并发或大数据量计算等单台服务器无法处理的任务。

四、微服务架构

微服务架构是分布式架构的一种，微服务架构能更好的支持互联网业务对十二范式的应用，特别适合对可用性、性能、扩展性、伸缩性要求比较高的应用场景。

微服务架构把单体应用垂直拆分成多个小的模块，每个模块都是一个完整的、自包含的服务，每个服务可以被独立的开发、部署，对外提供API，并且可以独立被调用，可以独立演化。

微服务的核心模式包括API网关、配置中心、服务注册与发现、熔断器、分布式追踪等。

五、微服务与强一致性的统一

微服务架构在带来诸多优势的同时，也带来很多调整。如当系统被拆分为多个服务的时候，强一致性保障的事物是一个挑战。如果使用分布式事务，那么就不得不牺牲系统的可扩展性，并放弃更高的高性能。通常的原则是：功能上比较内聚的，尤其是拥有强一致性事务的功能，会放在同一个微服务里。但如果要求高并发（如12306网站），把所有强一致性事务的功能放在一个微服务里，反而是一个灾难。此时，采用一些缓解措施，可以适当的牺牲这种强一致性，转而变成一种最终一致性。CQRS架构便是一种最终一致性架构。

实施微服务架构，需要有良好的DevOps和底层基础架构来支撑。