云时代架构读后感7-架构设计思维

原文地址：

 http://mp.weixin.qq.com/s?__biz=MzAwNTQ4MTQ4NQ==&mid=2453562422&idx=1&sn=778a67331951f177e36c4e6ecaabaea1&chksm=8cd13154bba6b842638ec4e0d6f9b53b7673629ed2e7dbccd87b73d1409de0fbd4f48d409024&mpshare=1&scene=23&srcid=#rd 

 

分而治之是一种处理复杂问题的通用方法，在系统架构中也是一种很重要的手段，例如多层架构、OSI 七层模型都体现了分而治之思想。

在架构设计过程中，通过将关注点分离对架构进行多层次分解，将系统层层分解为多个架构元素，进而识别架构元素。同时保证分解后的各个部分还能够高内聚，松耦合，最终又集成为一个完整的整体。

分解核心是定义问题，因此架构首先仍然需要理解清楚需求。

架构分解是架构师接到需求到完成架构设计中最关键的一步，分解可以帮助架构师了解需求中未呈现出来的隐性需求要素，分解也是架构师解决非功能层面需求的重要手段，架构要解决高性能、高可用、伸缩性、可扩展性等问题，针对这些问题，我们一般从几个方面进行入手：

1. 应用层：按照功能或者微服务进行分解，将系统划分未若干子系统，低耦合存在，在业务角度可以将单个应用独立为应用单元（应用单元是无状态的），这样可以灵活地进行伸缩。

2. 数据层：对数据库进行垂直拆分按照子系统纬度进行分库和水平拆分按照业务纬度进行分表；但是进行分库分表中要避免分布式事务，实在无法避免可利用消息系统来进行规避。

3. 代码结构层：代码层一般分为三层，从下至上分别为：数据访问层、业务逻辑层（又或称为领域层）、表示层。这也是Java Web中重要的三层架构中的三个层次。区分层次的目的即为了“高内聚低耦合”的思想。

分解需要遵循几个原则：

01.业务原则

1. 单一责任原则：对于一个微服务而言，具有有限的业务范围，可以帮助我们满足服务开发和交付的敏捷性；

2. 适当的边界：关注微服务的功能范围，一个服务的大小应该等于满足某个特定业务能力所需要的大小；

3. 业务分层： 从整体规划上把业务分层，形成单向依赖，避免微服务之间的网状依赖关系；

4. 颗粒度递增：设计初期先把业务划分到尽可能细，然后依据其它原则合并到适当颗粒度；

5. 非唯一依赖：至少被2个以上其它微服务依赖的功能模块，才有必要独立成一个微服务。

02.技术原则

1. 部署独立性：能独立于其它微服务部署，一个微服务故障不影响其它微服务；

2. 动态扩展：每个微服务都可以动态的进行x轴和z轴的扩展，并适应云环境下的自动化部署；（ 参考这里 ）

3. 领域和应用解耦：提供数据操作能力的领域服务和执行业务逻辑的应用服务解耦；

4. 避免产生频繁的跨库查询；

5. 避免产生频繁的分布式事务。

03.治理原则

1. 在业务分层的基础上，根据业务细分规则，对微服务分组；

2. 各个分组之间通过API网关集成；

3. 通过API网关实现级轻量级消息路由，鉴权；

4. 运行时管理，如服务降级，限流，监控等可在API网关实现，让微服务功能纯粹；

5. 避免通过数据库集成；

6. 避免部署多个版本来兼容。

分解的过程：

1.业务需求分解

2.业务功能需求分解

3.技术需求分解

4.架构需求分解