[TOC]

思想上的原则

墨菲定律

如果事情有变坏的可能,不管这种可能性有多小,它总会发生。

主要内容:

  1. 任何事都没有表面看起来那么简单;
  2. 所有的事都会比你预计的时间长;
  3. 会出错的事总会出错;
  4. 如果你担心某种情况发生,那么它就更有可能发生。

实践感悟:

设计系统时思想上要时刻保持警惕,复杂度低估、工时低估、小概率风险等等

康威定律

设计系统的企业受限于生产设计,这些设计是企业沟通结构的副本——Melvin Conway(1967)。

主要内容:

  1. 系统架构是公司组织架构的反映
  2. 按照业务闭环进行系统拆分/组织架构划分,实现闭环、高内聚、低耦合,减少沟通成本
  3. 如果沟通出现问题,就应该考虑进行系统或者组织架构的调整
  4. 在合适的实际进行系统拆分,不要一开始就把系统/服务拆分的非常细,虽然闭环,但是每个人负责的系统多、维护成本高。

扩展阅读:

参考:《康威定律与微服务》https://segmentfault.com/a/1190000011118897

参考:《阿里中台与组织架构》https://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=2651018922&idx=1&sn=26ac29a28433ce64f65a7675ddc0b546&chksm=bdbeaef98ac927efce317a5bae726db2c847eab77c8ccffe0f38ea1f246aaa12aa4674d3bff7&mpshare=1&scene=1&srcid=0830eUq2v2oIsq8j0x1V1Kr0&sharer_sharetime=1567160444279&sharer_shareid=206d028041d7f364aa6e82c9398ea525#rd

实践感悟:

系统边界的定义往往与组织架构有关;良好的组织架构能提供系统设计的合理性;好的系统慢慢演化的过程中必然会不断的存在系统边界调整或者组织架构的调整。

二八定律

人月神话,增加人手可能会进一步的降低效率,故资源的限制约束永远存在。好钢用在刀刃上,以最小化可行产品的方式迭代推进系统演进。

高并发原则

无状态

设计无状态的应用,便于水平扩展的应用;依赖分布式架构来应付高并发。

实践感悟:

应用无状态就是应用实例不存在本地状态,任何一个请求由任何一个实例处理结果都是一致的。

简单说,应用不要本地文件系统和内存系统,除非你有分布式方案。

思考:

《snowflake算法是有状态的吗?》https://nicky-chen.github.io/2018/09/19/id-snowflake/

《Kafka有状态分布式》http://kafkadoc.beanmr.com/040_design/01_design_cn.html

拆分

在系统设计初期是做成ALL In One系统还是按功能模块拆分系统需要根据环境权衡。在实际企业级开发中系统的拆分是不可避免,可能是因为系统复杂性、也可能是访问量,另外投入的资源量也是一个重要的考量。

常见的系统拆分方案有以下几种:

  1. 系统维度拆分:按照系统的功能、业务进行拆分
  2. 功能维度拆分:对一个系统进行功能再拆分,比如优惠系统可以进一步拆分为优惠券、满减、领券等
  3. 读写维度拆分:按照业务的读写特性拆分,比如商品系统的读请求量远远大于写请求量,可以拆分为商品查询服务和商品修改服务,商品查询服务重点在于缓存降低响应时间提高查询效率、写服务核心在审核等管理功能
  4. 按照AOP维度拆分:按照访问特征进行整合,比如页面渲染、CDN管理等
  5. 模块维度拆分:按照基础或者代码维护特性进行拆分,比如数据库连接池、分库分表;代码结构一般按照三层架构

服务化

  1. 首先判断单点的远程服务调用是否可以满足,如果不能满足那么集群是否可以解决?
  2. 考虑在客户端注册多台主机并使用Nginx进行负载均衡是否可行。
  3. 当服务原来越多,可以进一步考虑服务的自动注册与发现。
  4. 进一步随着服务的依赖关系与调用关系越来越复杂,我们应该对服务进行分组与链路梳理。完成服务分层、服务分级、服务隔离,此时还需要考虑限流、黑白名单、降级等;从而进一步提高服务的可靠性提供柔性可降级服务。

进程内服务>单机RPC>集群PRC>自动注册与发现>服务分级>服务治理框架

消息队列

消息队列方案天生就附带了服务解耦(消息体结构接口、一对多消费等)、异步化的特性,依赖消息中间件的堆积能力还能起到削峰填谷的作用,另外依赖消息延迟我们也可以完成事务验证、数据核对。但同时消息队列也会带来事务分割、消息失败(丢失、消费失败)、幂等重试等问题。

##