云时代架构阅读笔记十五——架构设计思维（一）

对于架构设计人们已经提出了许多方法，分类为：工件驱动的方法；用例驱动的法；模式驱动的方法；领域驱动的方法。一个经典的架构设计过程模型，沿用了RUP中迭代增量的思想，由分析、描述、选择、构造和组合5个阶段组成。

依据需求规格说明书分析出功能需求和架构需求，通过用例和场景的描述，把需求分为关键的，次要的和可选的3类。关键需求决定架构，结合软件架构风格和通用知识选择最关键、影响最大的子系统分析设计并产生构件。组合就是定义构件接口，构件作为一个封闭的功能实体，对外提供交互接口，并通过连接件将构件连接起来形成最终的软件架构描述。5个阶段是不断迭代的过程，在每一次迭代中，都选取并实现一组用例和场景来确认并完善架构。

这个过程模型看似很流畅，但是，架构师在设计时很难把握他的正确性和精准性，而且用它架构的系统是否对后续设计开发形成一种原则上的指导是很难说的。但是对于架构师来说有些思路可以进行参考，大致将架构思维可以分为：分解、集成、分离、复用、分层、模式、抽象、结构化、迭代、勿做过度设计这几部分，按照这个思维方式来设计系统架构。

分而治之是一种处理复杂问题的通用方法，在系统架构中也是一种很重要的手段，例如多层架构、OSI 七层模型都体现了分而治之思想。在架构设计过程中，通过将关注点分离对架构进行多层次分解，将系统层层分解为多个架构元素，进而识别架构元素。同时保证分解后的各个部分还能够高内聚，松耦合，最终又集成为一个完整的整体。分解核心是定义问题，因此架构首先仍然需要理解清楚需求。

分解的作用：

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

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

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

       分解的原则：

       业务原则：

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

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

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

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

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

技术原则：

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

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

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

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

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

治理原则：

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

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

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

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

避免通过数据库集成；

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