在这里可以找到AWS相关的白皮书下载链接。 本文内容主要来自于架构师助理培训内容的提纲。 详情参见此文档。

在撰写、翻译时尽量隐去了对应AWS服务的引用，取而代之的是对应功能的描述。此举不是因为担心为AWS做广告（人家也不需要），是因为好的架构思想应该不应受到平台的限制。经过时间和实践考验过的组件，一定会在其它平台换个名字重新实现。

“松耦合使你自由”

  • 基于独立组件设计架构
    1. 耦合度越松散，越容易进行横向扩展

解耦原则

  • 不要依赖特定对象，考虑使用：
    1. 负载均衡集群
    2. DNS域名解析
    3. 可配置的路由表
  • 不要依赖其他服务的健康状况
    1. 使用异步消息代替方法调用

“将组件故障的情况加入到架构考虑的范围内”

原文：Design for failure and nothing will fail. 是一句很耐人寻味的话。

  • 在设计每个组件时都要考虑：如果他挂掉了会怎样。多个组件形成资源组后，再次问自己这个问题。
  • 设计持续可用、能够自我修复的组件。
  • 高可用
    1. 架构中的任何一个组件完全崩溃时不能影响整个系统。
  • 容错
    1. 架构中的任何一个组件完全崩溃时不能影响整个系统并且不会降低系统的性能

从这个角度看，容错是在高可用后进一步需要考虑的问题。例如：某些组件崩溃时，断路器可以减少无效访问的重试次数，节约计算资源及等待时间，并且保证崩溃的组件不会进一步污染整个系统。

实现弹性

  • 不要假定服务的可用性、健康状态以及位置是一成不变的
    1. 使用弹性扩展、弹性IP、可用区
  • 设计可以通过冷/热重启恢复的服务
    1. 无状态比有状态好
    2. 使用弹性负载均衡和云监控检测实例的健康状况
  • 引导实例的启动过程
    1. 例如：在启动时传入用户信息判别实例属于个人还是角色
  • 推荐在实例外储存配置及个性化信息
    1. 例如Key-Value的NoSQL数据库服务
  • 弹性设计通常有利于节约开支

每个层面都需要考虑安全问题

  • 基础设施层
  • 计算、网络架构层
  • 数据层
  • 应用层

  1. 在某些架构模型中，API Gateway还同时提供拦截非法请求的功能，保护网关后服务不被非法访问。当Api Gateway被攻破后，如若后面的服务及设施没有进行安全架构，所有的通信、接口将一览无余。

  2. Intel的熔断漏洞波及了几乎所有Intel的用户。有计划的及时安装系统更新是必要的。如果带宽成本高昂请考虑Update Proxy。

1.有些机密数据能提供便利及商业价值，因此黑客总是热衷于拖库。如果不储存这些敏感数据，黑客就无从下手，其他企业和政府也不会威胁和索取这些数据。（据说微信就不会保存用户的聊天记录。）

  1. 尽量不要在版本控制工具中保存凭据及秘钥文件。一旦提交至服务器，这些信息将很难剔除。如果在Github提交了私钥，很快你就会收到潜在安全风险的邮件。可以通过凭据管理服务来进行凭据的管理及获取。

最小授权原则

  • 只付于操作者完成工作的必要权限
    1. 必须对个人和进程进行授权
    2. 只有三类用户可以直接访问资源配置型API
      1. 主账号
      2. 具备管理员角色的授权用户
      3. 使用安全令牌授权的服务

这就是为什么EF Code First无法初始化Aliyun的RDS服务。(: