企业级架构设计原则

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

架构解决的问题

架构作为构架在业务与技术之间鸿沟的桥梁，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