关于架构设计的学习记录

什么是架构



Linux有架构，MySQL有架构，JVM也有架构，使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构，应该关注哪一个？想要清楚以上问题需要梳理几个有关系又相似的概念：

1. 系统与子系统



系统：泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能独立完成的工作能力的群体。

子系统：也是由一群关联的个体组成的系统，多半是在更大的系统中的一部分。

2. 模块与组件



都是系统的组成部分，从不同角度拆分系统而已。模块是逻辑单元，组件是物理单元。



模块就是从逻辑上将系统分解，即分而治之，将复杂问题简单化。模块的粒度可大可小，可以是系统，几个子系统、某个服务，函数，类，方法、功能块等等。



组件可以包括应用服务、数据库、网络、物理机、还可以包括MQ、容器、Nginx等技术组件。

3. 框架与架构



框架是组件实现的规范，例如：MVC、MVP、MVVM等，是提供基础功能的产品，例如开源框架：Ruby on Rails、Spring、Laravel、Django等，这是可以拿来直接使用或者在此基础上二次开发。



框架是规范，架构是结构。



我在这重新定义架构：软件架构指软件系统的顶层结构。



架构是经过系统性地思考，权衡利弊之后在现有资源约束下的最合理决策，最终明确的系统骨架：包括子系统、模块、组件，以及他们之间的协作关系、约束规范、指导原则，并由它来指导团队中的每个人思想层面上的一致。



涉及四方面：

1. 系统性思考的合理决策：比如技术选型、解决方案等。

2. 明确的系统骨架：明确系统有哪些部分组成。

3. 系统协作关系：各个组成部分如何协作来实现业务请求。

4. 约束规范和指导原则：保证系统有序，高效、稳定运行。

因此架构师具备的能力有：理解业务、全局把控、选择合适技术、解决关键问题、指导研发落地实施。



架构的本质就是对系统进行有序化地重构以致符合当前业务的发展，并可以快速扩展。



那什么样的系统要考虑做架构设计？技术不会平白无故的出现和自驱动发展起来，而架构的发展和需求是基于业务的驱动的。



架构设计完全是为了业务：

1. 需求相对复杂

2. 非功能性需求在整个系统占据重要位置

3. 系统生命周期长，有扩展性需求

4. 系统基于组件或者集成的需要

5. 业务流程有再造的需要

架构分层和分类



架构分类可细分为业务架构、应用架构、技术架构、代码架构、部署架构。



业务架构是战略，应用架构是战术，技术架构是装备。其中应用架构承上启下，一方面承接业务架构的落地，另一方面影响技术选型。



熟悉业务，形成业务架构，根据业务架构，做出相应的应用架构，最后技术架构落地实施。



如何针对当前需求，选择合适的应用架构，如何面向未来，保证架构平滑过渡，这是软件开发者，特别是架构师，都需要深入思考的问题。

1. 业务架构（俯视架构）



包括业务规划、业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。



没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往会给系统带入大坑，任何不基于业务做异想天开的架构都是耍流氓。



所有问题的前提是要搞清楚现在面临的业务量有多大，增长走势是什么样，而且解决高并发的过程，一定是一个循序渐进逐步的过程。合理的架构能够提前预见业务发展1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。



看看京东业务架构（网上分享图）：



2.jpg



2. 应用架构（剖面架构，也叫逻辑架构图）



应用架构：应用作为独立可部署的单元，为系统划分了明确的边界，深刻影响系统功能组织、代码开发、部署和运维等各方面。应用架构定义系统有哪些应用、以及应用之间如何分工和合作。这里所谓应用就是各个逻辑模块或者子系统。



应用架构图关键有2点：

职责划分：明确应用（各个逻辑模块或者子系统）边界

• 逻辑分层

• 子系统、模块定义

• 关键类

职责之间的协作：

• 接口协议：应用对外输出的接口

• 协作关系：应用之间的调用关系

应用分层有两种方式：

• 一种是水平分（横向），按照功能处理顺序划分应用，比如把系统分为Web前端/中间服务/后台任务，这是面向业务深度的划分。

• 另一种是垂直分（纵向），按照不同的业务类型划分应用，比如进销存系统可以划分为三个独立的应用，这是面向业务广度的划分。

应用的合反映应用之间如何协作，共同完成复杂的业务case，主要体现在应用之间的通讯机制和数据格式，通讯机制可以是同步调用/异步消息/共享DB访问等，数据格式可以是文本/XML/JSON/二进制等。



应用的分偏向于业务，反映业务架构，应用的合偏向于技术，影响技术架构。分降低了业务复杂度，系统更有序，合增加了技术复杂度，系统更无序。



应用架构的本质是通过系统拆分，平衡业务和技术复杂性，保证系统形散神不散。



系统采用什么样的应用架构，受业务复杂性影响，包括企业发展阶段和业务特点；同时受技术复杂性影响，包括IT技术发展阶段和内部技术人员水平。业务复杂性（包括业务量大）必然带来技术复杂性，应用架构目标是解决业务复杂性的同时，避免技术太复杂，确保业务架构落地。

3. 数据架构



数据架构指导数据库的设计，不仅仅要考虑开发中涉及到的数据库，实体模型，也要考虑物理架构中数据存储的设计。



4.png



4. 代码架构（也叫开发架构）



子系统代码架构主要为开发人员提供切实可行的指导，如果代码架构设计不足，就会造成影响全局的架构设计。比如公司内不同的开发团队使用不同的技术栈或者组件，结果公司整体架构设计就会失控。



代码架构主要定义：

代码单元：

• 配置设计

• 框架、类库

代码单元组织：

• 编码规范，编码的惯例

• 项目模块划分

• 顶层文件结构设计，比如MVC设计

• 依赖关系



5. 技术架构



技术架构，确定组成应用系统的实际运行组件（LVS，Nginx，Tomcat，PHP-FPM等），这些运行组件之间的关系，以及部署到硬件的策略。



技术架构主要考虑系统的非功能性特征，对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握。



系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这也是架构设计工作中最为困难的工作。



6. 署拓扑架构图（实际物理架构图）



拓扑架构，包括架构部署了几个节点，节点之间的关系，服务器的高可用，网路接口和协议等，决定了应用如何运行，运行的性能，可维护性，可扩展性，是所有架构的基础。下面这个图主要是运维工程师主要关注的对象。



物理架构主要考虑硬件选择和拓扑结构，软件到硬件的映射，软硬件的相互影响。



7.png



架构级别



我们使用金字塔的架构级别来说明，上层级别包含下层：



8.jpg



• 系统级，即整个系统内各部分的关系以及如何治理分层。

• 应用级，即单个应用的整体架构，及其与系统内单个应用的关系等。

• 模块级，即应用内部的模块架构，如代码的模块化、数据和状态的管理等。

• 代码级，即从代码级别保障架构实施。

基于架构金字塔，我们有了系统架构的战略设计与战术设计的完美结合：

• 战略设计：业务架构用于指导架构师如何进行系统架构设计。

• 战术设计：应用架构要根据业务架构来设计。

• 战术实施：应用架构确定以后，就是技术选型。



应用架构演进



业务架构是生产力，应用架构是生产关系，技术架构是生产工具。业务架构决定应用架构，应用架构需要适配业务架构，并随着业务架构不断进化，同时应用架构依托技术架构最终落地。



架构演进路程：单体应用->分布式应用服务化->微服务



1. 单体应用



企业一开始业务比较简单，只应用某个简单场景，应用服务支持数据增删改查和简单的逻辑即可，单体应用可以满足要求。



典型的三级架构，前端（Web/手机端）+中间业务逻辑层+数据库层。这是一种典型的Java Spring MVC或者Python Django框架的应用。其架构图如下所示：



针对单体应用，非功能性需求的做法：

• 性能需求：使用缓存改善性能

• 并发需求：使用集群改善并发

• 读写分离：数据库地读写分离

• 使用反向代理和CDN加速

• 使用分布式文件和分布式数据库

单体架构的应用比较容易部署、测试，在项目的初期，单体应用可以很好地运行。然而，随着需求的不断增加，越来越多的人加入开发团队，代码库也在飞速地膨胀。慢慢地，单体应用变得越来越臃肿，可维护性、灵活性逐渐降低，维护成本越来越高。下面是单体架构应用的一些缺点：

• 复杂性高，以一个百万行级别的单体应用为例，整个项目包含的模块非常多、模块的边界模糊、依赖关系不清晰、代码质量参差不齐、混乱地堆砌在一起。可想而知整个项目非常复杂。每次修改代码都心惊胆战，甚至添加一个简单的功能，或者修改一个Bug都会带来隐含的缺陷。

• 技术债务：随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越积越多。“不坏不修”，这在软件开发中非常常见，在单体应用中这种思想更甚。已使用的系统设计或代码难以被修改，因为应用程序中的其他模块可能会以意料之外的方式使用它。

• 部署频率低：随着代码的增多，构建和部署的时间也会增加。而在单体应用中，每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。全量部署的方式耗时长、影响范围大、风险高，这使得单体应用项目上线部署的频率较低。而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复，出错率比较高。

• 可靠性差：某个应用Bug，例如死循环、内存溢出等，可能会导致整个应用的崩溃。

• 扩展能力受限：单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。例如，应用中有的模块是计算密集型的，它需要强劲的CPU；有的模块则是IO密集型的，需要更大的内存。由于这些模块部署在一起，不得不在硬件的选择上做出妥协。

• 阻碍技术创新：单体应用往往使用统一的技术平台或方案解决所有的问题，团队中的每个成员都必须使用相同的开发语言和框架，要想引入新框架或新技术平台会非常困难。

2. 分布式



随着业务深入，业务要求的产品功能越来越多，每个业务模块逻辑也都变得更加复杂，业务的深度和广度都增加，使得单体应用变得越来越臃肿，可维护性、灵活性逐渐降低，增加新功能开发周期越来越长，维护成本越来越高。



这时需要对系统按照业务功能模块拆分，将各个模块服务化，变成一个分布式系统。业务模块分别部署在不同的服务器上，各个业务模块之间通过接口进行数据交互。



相对于单体架构来说，这种架构提供了负载均衡的能力，大大提高了系统负载能力，解决了网站高并发的需求。另外还有以下特点：

• 降低了耦合度：把模块拆分，使用接口通信，降低模块之间的耦合度。

• 责任清晰：把项目拆分成若干个子项目，不同的团队负责不同的子项目。

• 扩展方便：增加功能时只需要再增加一个子项目，调用其他系统的接口就可以。

• 部署方便：可以灵活的进行分布式部署。

• 提高代码的复用性：比如Service层，如果不采用分布式REST服务方式架构就会在手机WAP商城，微信商城，PC，Android，iOS等每个端都要写一个Service层逻辑，开发量大，难以维护一起升级，这时候就可以采用分布式REST服务方式，公用一个Service层。

• 缺点：系统之间的交互要使用远程通信，接口开发增大工作量，但是利大于弊。

3. 微服务



紧接着业务模式越来越复杂，订单、商品、库存、价格等各个模块都很深入，比如价格区分会员等级，访问渠道（APP还是PC），销售方式（团购还是普通）等，还有大量的价格促销，这些规则很复杂，容易相互冲突，需要把分散到各个业务的价格逻辑进行统一管理，以基础价格服务的方式透明地提供给上层应用，变成一个微内核的服务化架构，即微服务。



微服务的特点：

• 易于开发和维护：一个微服务只会关注一个特定的业务功能，所以它业务清晰、代码量较少。开发和维护单个微服务相对简单。而整个应用是由若干个微服务构建而成的，所以整个应用也会被维持在一个可控状态。

• 单个微服务启动较快：单个微服务代码量较少，所以启动会比较快。

• 局部修改容易部署：单体应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。

• 技术栈不受限：在微服务架构中，可以结合项目业务及团队的特点，合理地选择技术栈。例如某些服务可使用关系型数据库MySQL；某些微服务有图形计算的需求，可以使用Neo4j；甚至可根据需要，部分微服务使用Java开发，部分微服务使用Node.js开发。

微服务虽然有很多吸引人的地方，但它并不是免费的午餐，使用它是有代价的。使用微服务架构面临的挑战：

• 运维要求较高：更多的服务意味着更多的运维投入。在单体架构中，只需要保证一个应用的正常运行。而在微服务中，需要保证几十甚至几百个服务服务的正常运行与协作，这给运维带来了很大的挑战。

• 分布式固有的复杂性：使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的挑战。

• 接口调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有使用了该接口的微服务都需要做调整。

• 重复劳动：很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，从而导致代码重复。尽管可以使用共享库来解决这个问题（例如可以将这个功能封装成公共组件，需要该功能的微服务引用该组件），但共享库在多语言环境下就不一定行得通了。