当我们在为新的产品或者项目进行系统架构设计、制定演进路线、技术选型的时候，我们需要一些架构原则，来指导我们的架构设计和选型。
架构解决的问题
架构作为构架在业务与技术之间鸿沟的桥梁，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