企业级架构设计原则

当我们在为新的产品或者项目进行系统架构设计、制定演进路线、技术选型的时候,我们需要一些架构原则,来指导我们的架构设计和选型。

架构解决的问题

架构作为构架在业务与技术之间鸿沟的桥梁,e.g:业务需求 --> 架构 --> 技术实现
其主要目的:

为了解决当下或未来软件系统复杂度带来的问题,而架构其实并非设计出来,而是随着业务的发展逐步演变出来的结果

架构的一些原则

1.Security - Built security in, “安全”带来的品牌名声损失、用户流失、金钱的直接损失,都是企业级应用不能容忍的事故。

可参考的实践:

  • 端到端的加密,传输的数据通过SSL加密,e.g: Request -> ELB(https) -> EC2(https)

  • 根据系统不同的用途,将各个系统进行网络分区,设置不同的防火墙

2.Scalability - 动态伸缩, 至少支持两个维度的伸缩,比如水平伸缩和垂直伸缩。

可参考的实践:

  • 根据用户访问量或系统负载,进行水平的增加或者减少服务器实例

  • 可根据Segment分流,比如产品线类型,多品牌划分。

3.Resilient to Failures - 健壮性,容错

可参考的实践:

  • 为API设置timeouts,重试机制

  • 异步优于同步集成

  • 设置自动熔断,做到服务降级的同时,为终端用户提供有意义的信息

  • 防御性代码和测试

  • 通过ELB或者F5,隔离内部服务与用户的交互的直接交互,屏蔽内部服务状态变化对用户操作的影响。

4.Logs,Instrumented and Monitored - 日志与监控

可参考的实践:

  • 分布式追踪, e.g: dynatrace,zipkin等

  • 中心化日志管理, e.g: splunk

  • 服务监控与告警, 定义监控指标,设置告警触发条件

5.Configurable - 可配置,将系统容易变化的部分,通过配置进行管理

可参考的实践:

  • 前端样式styleguide的可配置,可以轻易更换网站风格(换皮肤)

  • 功能的可配置,比如feature toggle

  • 熔断器的可配置

  • 配置服务器,比如Spring cloud config server,实现配置的动态管理

6.Automated - 自动化一切可以自动化的任务

可参考的实践:

  • CI & CD

7.Modular - 模块化

可参考的实践:

  • 划分清楚的职责 - Single responsibility of a component (done well)

  • 关注点分离

  • 高内聚,低耦合

  • Just good enough - not over engineered

8.Reuse - 重用已用API资产,避免不必要的重复构建

可参考的实践:

  • API文档,e.g: SwaggerUI

  • API资产管理,比如有些商用的API Gateway, Axway能够集中管理所有注册的API生命周期

9.Predictable - Release - 可控发布,而不是祈祷式发布

可参考的实践:

  • 增量发布

  • 回滚计划

  • 蓝绿部署

  • 灰度发布

  • 隔离持续集成和持续部署

10.Consume over Rent over Buy over Build,除非需要构建Core能力,优先选择Build,否则依次考虑Consume > Rent > Buy > Build

你可能感兴趣的:(企业级架构设计原则)