程序员架构师转型之路笔记（一）概述

废话不多说直接开始。

前言

        读《系统设计架构》有感，对全书进行总结和概括，提炼关键信息，为自己也为广大读者架构师提供技术和知识支撑。

参考文档：《系统设计架构》 郑天民著 人民邮电出版社 2017年第一版

1.架构设计的基本概念

        架构设计的目的是对系统进行高度抽象，通过一系列设计原则，在最大程度上降低系统复杂度，解决系统中存在的各种共性和特殊性问题。

1. 1架构的基本定义

针对架构的定义和工作内容，业界有一些统一的说法，形成两大理论体系

• 架构组成理论
• 架构决策理论

1.1.1 架构组成理论

        国际标准化组织（ISO）：架构是一系列基本概念或者系统在其环境中表现出来的属性，体现在其元素、关系、设计和发展原则中。

（1）系统元素

        包括模块、组件、接口、子系统等日常开发流程中的内容。元素和元素之间的关系构成了系统架构的基础。通常架构师感兴趣的结构类型包括：静态结构和动态结构。

• 静态结构：设计时，描述系统内部设计的元素及其组合方式
• 动态结构：关注运行时，元素及其交互方式

（2）基本系统属性

一方面包含功能属性，说明系统有什么功能，例如：输入输出模型。

一方面为质量模型，如性能、安全性等属性。

（3）设计和发展原则

架构的设计发展应当可以可度量、可测试、可跟踪。例如：

• 用户操作响应时间应当<1s，而不是主观的感受
• 用户信息需要进行安全性处理
• 系统可以快速集成第三方服务
• ……针对每一个项目进行自定义原则

总结

        组成理论首先关注系统的主要构成部分以及他们之间的关系，然后进一步挖掘每个构成部分的细节。例如web开发中的MCV模式，就是典型的架构组成理论派的模式。

1.1.2 架构决策理论

        该理论从人的决策出发，包括非功能性需求的决策。当项目初期对于模块、模块交互方式不确定的情况下，可以采用决策模式。针对场景问题进行不断决策，来进行架构设计的开发和完善。

        整个系统的设计，则是依照架构原则，将系统分解。每个模块专注以自己的功能和实现。再下一层，每个块，又根据需求，分解不同的架构问题，然后经过架构决策一一解开。这种自上而下，既能服务整体，又能将问题分而治之的思考模式。

1.2 架构演进理论

        当系统中分布式服务数量和种类增多，而这些服务又分别属于不同业务层次时，如何合理地管理这些服务之间的调用关系，进一步确保系统的健壮性和扩展性成为系统架构设计的又一大难题。分布式服务的自身特征决定了其在时间、空间和技术上都具有一定程度的系统耦合性。在使用分布式服务时需要谨慎处理服务调用的时序、所使用的服务定义及技术平台的差异性等问题。这些问题为开展快速架构重构和扩展、进行高效分布式团队协作带来了挑战。以各种消息传递组件为代表的中间件系统为降低系统耦合性、屏蔽技术平台差异性带来了新的思路。当不同的服务需要进行交互、但又不需要直接进行服务的定位、调用和管理时，消息中间件（Middleware）能显著降系统的耦合程度。

        试想这样一种场景，我们的系统需要跟外部的多个系统进行集成以形成关键业务链路闭环管理，而这些外部系统分别部署在其他供应商或客户环境，并且每个系统都可能基于完全不同的技术平台和体系构建，随着业务发展需求，这些外部需求还需要实现动态的注册和注销。对系统架构设计而言，一方面我们需要整合这些外部系统提供的服务进行数据的获取和操作，另一方面，我们又不希望我们的系统对它们产生强依赖。消息中间件在这种场景下已经失去系统解耦的价值，因为外部系统不在控制范围之内，我们对其内部实现原理一无所知。如何在异构系统、分布式服务和基于租户的基本架构需求下实现有效的系统集成，企业服务总线（Enterprise Service Bus，ESB）提供了相应的解决方案。通过在核心业务服务中引入ESB及对应的路由、过滤、转换、端点等系统集成模式，即可屏蔽由于技术差异性导致的各种系统集成问题，并动态管理ESB上的第三方服务。