闲来无事，总结了下架构设计方面的一些思考
1、稳定性
。一切以稳定为中心
。架构尽可能简单、清晰
。不过度设计
2、解耦/拆分
。稳定部分与易变部分分离
。核心业务与非核心业务分离
。主流程与辅流程分离
。应用与数据分离
。服务与实现细节分离
。数据拆分：读写分离、分库分表、冷热数据分离
3、抽象化
。应用抽象化：应用只依赖服务抽象，不依赖服务实现细节、位置
。数据库抽象化：应用只依赖逻辑数据库，不需要关心物理库的位置和分片
4、松耦合
。跨域调用异步化：不同业务域之间尽量异步解耦
。非核心业务尽量异步化：核心、非核心业务之间，尽量异步解耦
。必须同步调用时，需要设置超时时间和任务队列长度
5、高可用
。集群容错：应用系统集群，避免单点
。多机房容灾，异地多活
。分流：水平可扩展-在线扩容机器
。降级：非核心业务可根据情况降级处理（业务直接不展示或mock数据或直接利用本地缓存）
。限流：对流量做过滤，保证部分请求可用
。自动化运维
6、灵活
。支持灰度发布，分步切流量
。功能开关，可回退
。A/B test，配备相应数据展示层，及时感知数据变化
7、监控
。服务器监控：内存、cpu、i/o、负载
。应用监控：qps、rt、gc
。异常监控报警
。分布式链路追踪监控：zipkin、pinpoint
。业务监控：核心业务生命周期监控，比如根据订单号获取所有相关生命周期和数据
8、领域建设
。厘清业务边界，建设领域模型
。基础业务/服务下沉，可复用
。平台/组件化：可搭积木式构建新业务，降低成本
。数据收敛：只能通过服务来访问其他领域的数据
9、依赖原则
。禁止循环依赖
。稳定部分依赖：稳定部分不依赖易变部分、易变部分可以依赖稳定部分
。核心服务依赖：核心服务不依赖非核心服务、非核心服务可依赖核心服务，保证核心服务稳定
。基础服务依赖：基础服务不向上依赖流程服务、流程服务/组合服务可向下依赖基础服务，保证基础服务稳定
。平台服务依赖：平台服务不依赖上层应用、上层应用可依赖平台服务，保证平台服务稳定
。非功能性服务依赖：非功能性服务不依赖功能性服务、功能性服务可依赖非功能性服务，保证非功能性服务稳定
。跨业务域调用时，尽可能异步弱依赖
10、服务设计
。无状态，接口调用幂等
。可复用，复用粒度是有业务逻辑的抽象服务，不是服务细节
。松耦合、高内聚
。可治理
。基础服务之间物理隔离，包括数据层
写了这么多，无非就是围绕稳定性、可扩展性、易用性、灵活性展开的，其中重中之重是稳定性
失去了稳定性，其他一切都是扯淡
另外，架构必须紧贴业务，抛开了业务，所有技术也都是扯淡，产生不了价值