架构思考

闲来无事，总结了下架构设计方面的一些思考

    一、稳定性

            。一切以稳定为中心

            。架构尽量简单、清晰

            。不过分设计

    二、解耦/拆分

            。稳定部分与易变部分分离

            。核心业务与非核心业务分离

            。主流程与辅流程分离

            。应用与数据分离

            。服务与实现细节分离

            。数据拆分：读写分离、分库分表、冷热数据分离

    三、抽象化

            。应用抽象化：应用只依赖服务抽象，不依赖服务实现细节、位置

            。数据库抽象化：应用只依赖逻辑数据库，不须要关心物理库的位置和分片

    四、松耦合

            。跨域调用异步化：不一样业务域之间尽可能异步解耦

            。非核心业务尽可能异步化：核心、非核心业务之间，尽可能异步解耦

            。必须同步调用时，须要设置超时时间和任务队列长度

    五、高可用

            。集群容错：应用系统集群，避免单点

            。多机房容灾，异地多活

            。分流：水平可扩展-在线扩容机器

            。降级：非核心业务可根据状况降级处理（业务直接不展现或mock数据或直接利用本地缓存）

            。限流：对流量作过滤，保证部分请求可用

            。自动化运维

    六、灵活

            。支持灰度发布，分步切流量

            。功能开关，可回退

            。A/B test，配备相应数据展现层，及时感知数据变化

    七、监控

            。服务器监控：内存、cpu、i/o、负载

            。应用监控：qps、rt、gc

            。异常监控报警

            。分布式链路追踪监控：zipkin、pinpoint

            。业务监控：核心业务生命周期监控，好比根据订单号获取全部相关生命周期和数据

    八、领域建设

            。厘清业务边界，建设领域模型

            。基础业务/服务下沉，可复用

            。平台/组件化：可搭积木式构建新业务，下降成本

            。数据收敛：只能经过服务来访问其余领域的数据

    九、依赖原则

            。禁止循环依赖

            。稳定部分依赖：稳定部分不依赖易变部分、易变部分能够依赖稳定部分

            。核心服务依赖：核心服务不依赖非核心服务、非核心服务可依赖核心服务，保证核心服务稳定

            。基础服务依赖：基础服务不向上依赖流程服务、流程服务/组合服务可向下依赖基础服务，保证基础服务稳定

            。平台服务依赖：平台服务不依赖上层应用、上层应用可依赖平台服务，保证平台服务稳定

            。非功能性服务依赖：非功能性服务不依赖功能性服务、功能性服务可依赖非功能性服务，保证非功能性服务稳定

            。跨业务域调用时，尽量异步弱依赖

    十、服务设计

            。无状态，接口调用幂等

            。可复用，复用粒度是有业务逻辑的抽象服务，不是服务细节

            。松耦合、高内聚

            。可治理

            。基础服务之间物理隔离，包括数据层

写了这么多，无非就是围绕稳定性、可扩展性、易用性、灵活性展开的，其中重中之重是稳定性

失去了稳定性，其余一切都是扯淡

另外，架构必须紧贴业务，抛开了业务，全部技术也都是扯淡，产生不了价值