技术架构设计原则
下面从不同维度给出技术架构的设计原则。
通用技术架构原则
- 业务需求导向原则：企业业务战略计划决定了企业架构的发展方向，同时决定了企业的整体IT架构。技术的首要任务是支撑业务发展，技术需要结合业务需求及业务架构、应用架构、数据架构的要求输入，从而快速实现IT投资的回报。
- 实用性原则：IT需要以实用为原则，不能一味地追求市场上最先进的技术平台，需要结合企业实际的业务发展。
- 复用原则：遗留的系统和数据都是宝贵的资产，在技术改造过程中，要最大限度地保护现有IT资产，并充分结合新一代技术架构的技术特点，在复用的基础上进行创新。
- 开放与标准化原则：尽量采用国际上通用的技术标准体系，充分考虑主流的开源及商业化选择。统一且成熟的技术标准可以保证系统的一致性和兼容性，同时减少企业在非功能性技术方面的投入。
- 分布式架构参考设计原则：一个良好的分布式系统需要充分综合考虑相关的能力，比如应用服务能力的线性扩展、高并发下的高性能响应、服务治理能力、数据化运营能力、全链路监控跟踪等。
- 尽可能应用无状态：仅当业务需要时才呈现使用状态，尽量保持应用无状态，这样更易于扩展。
- 尽可能异步设计：仅当无法异步时，才进行同步调用，尽量考虑异步设计。
技术架构标准和规范
- 架构模式标准化：包括应用平台的架构模式选型标准、微服务架构设计标准、应用平台开发标准等，通过统一的应用平台架构来规范应用的整体结构，并涵盖未来应用系统、遗留系统及需要集成与整合的系统。
- 技术选型标准：需要从企业实际角度提出技术选型管理标准，结合市场上主流开源和商业技术组件，以及企业技术的发展趋势，综合考虑技术的架构、功能、性能、集成难度、实施难度等因素。
- 基础设施选型标准：针对企业的服务器、存储、数据、网络等综合基础设施，比如采用云原生基础设施能力，充分考虑企业上云过程的利与弊。
- 系统非功能性能力管理：充分考虑系统的非功能性能力，权衡投入产出比，评估IT系统管理的复杂度，确定是否采用一系列开源或商业化产品加以辅助管理。
通用非功能性原则
提到非功能性，技术架构可能涉及多个方面，如稳定性、可扩展性、一致性、可移植性、兼容性、可配置性、可降级性、可部署性、可发现性、故障透明性、容错性、可检验性、可安装性、完整性、可维护性、可管理性、模块性、可操作性、可恢复性、可靠性、重现性、弹性、可复用性、稳健性、安全性、可服务性、合规性、可持续性、可测试性、可追溯性等。当然这些特性可能并不会在一个系统中全部满足，需要结合企业实际需求进行针对性的开展。下面是ISO/IEC 25010标准定义的系统软件产品质量中所考虑的非功能性，包括以下八大类别。
- 功能适合性：功能完整度、功能正确性和功能恰当性。
- 性能效率：响应时间、资源利用率和容量。
- 兼容性：多版本共存和互操作性。
- 易用性：可学习性、可运维性、自动纠错、UI美观度、可访问性。
- 可靠性：成熟度、容错性、可恢复性。
- 安全性：机密性、完整性、不可伪造性、权威性和可审计性。
- 可维护性：模块度、可复用性、可分析性、可修改性、可测试性。
- 可移植性：可适配性、可安装性、可替代性。
微服务设计原则
微服务设计原则如下所示，有的前文已提到过。
- 稳定性原则：以稳定为中心，设计得尽可能简单和清晰，不过度设计。
- 依赖和分离原则：需要把稳定的服务部分与易变的服务部分进行分离，把核心业务微服务与非核心业务微服务分离，应用与数据分离，服务接口与实现细节分离。
- 异步松耦合原则：不同业务域间尽量异步解耦；核心业务和非核心业务间尽量异步解耦。
- 垂直划分优先原则：尽可能根据业务领域进行服务的垂直划分，这样更加关注业务实现，端到端负责，便于持续改进，减少调用次数。水平划分需要充分从总体考虑。
- 持续演进原则：应逐步划分、持续演进，避免服务数量的“爆炸性”增长。当服务数量增加时，需要考虑持续交付、微服务监控与治理等环节。
- 服务自治原则：服务需要提供SLA，保持稳定性，可以独立开发、测试、部署和运行，避免发生连锁反应。
- 自动化驱动原则：可以结合DevOps和CI/CD等自动化工具，以及成熟的微服务治理框架，提高微服务生命周期的自动化效率。
- 微服务拆分原则：优先拆分比较独立的服务、通用服务、边界明显的服务、核心服务。
- 提前准备原则：开展微服务前需要做一些准备，比如研发环境和流程上的转变、构建自动化工具链、服务注册与发现、流量调度、监控等。