软件架构之个人见解_link66.cn短链接在线生成

架构是不断迭代改出来的，不是一次设计出来的，就像代码重构一样，需要一遍又一遍的梳理和迁移。原则是高可用性（99.99%）、可靠性、可扩展性(低耦合、抽像化、可水平扩展)、低成本、安全性、可维护性、可重用性、易用性（用户体验）、容错性。

冷热数据分离
随着数据库的数据量越来越大，比如添加字段时，它会做一些锁表操作，数据主从延迟以及一些锁表的时间会越来越长，所以在加字段的时候对生产影响特别大，我们需要对数据做一个分离，把一些冷的数据单独做一个历史库，剩下的实时库只留最近几天的一些生产需要的数据，这样生产库的订单数据量就会很小，每次修改表的时间是可控的，所以我们会把数据按照冷备进行拆分。所以可以mysql或es实时库存最新几天的数据，冷数据存全量数据。

至于为什么引入 ES，是因为比如订单在生产方面会有一些很复杂的查询，复杂查询对数据库的性能影响非常大，引入 ES 就可以很好地解决这个问题;另外还有一个重要原因是数据量大的情况下，使用传统的分库分表多少都存在一些问题，如热点、迁移与数据量分布不均等问题，而引入es后可以在一定程度很好的解决这些问题，且实现和维护成本也大大降低。

读写分离
就能很好地解决了数据库压力大的问题。很多查询，我们可以直接查询到从库的，主库只是用来承载一些写的流量，这样主库就减少了很多压力。但这样就会遇到上面说到的问题，因为我们是一个生产表和历史表的结构，在每次加字段时，数据量很多的话，锁表时间就会很长，导致在这种读写分离的架构下数据延迟就会比较大。

实时历史分离
冷热数据分离其实时在数据库层面需要做实时与历史的分离，业务模块拆分上也要做实时历史分离，折分后提升实时业务的响应与处理时间。

核心与非核心分离
下单、交易、支付业务是电商的核心业务，需要优先保证高可用，秒杀与拼团等活动业务对高并发要求高，应该与普通业务隔离。评价为非核心业务，对可用性要求并不高。功能要做开关，必要时可以停用部分非核心业务，保证核心业务的正常运行。

区分主流程与辅流程
运行时，优先保证主流程的顺利完成，辅流程采用后台异步的方式。避免辅流程失败导致主流程回滚，如下单后扣库存为同步操作，异常通知发货、发票、增加用户积分等为辅流程。

业务平台化与基础业务下沉
业务平台化，相互独立，明确界限与职责，如交易平台、仓储平台、物流平台、支付平台、广告平台。基础业务下沉，可复用，如用户、商品、订单、库存、活动、监控预警、短信。

一个企业的架构师团队，需要长期关注技术驱动业务、明确领域职责与边界等关键问题，同时架构的演进过程也是不断考虑 ROI 的权衡取舍过程。技术的持续发展，有助于不断提升用户体验、业务规模，降低运营成本，而架构在其中需要解决的问题就是化繁为简，将复杂问题拆解为简单的问题逐个攻破。随着企业规模的持续增长、业务的持续创新，会给系统架构提出越来越高的要求，所以系统架构设计将是我们长期研究的课题。在这条架构演进之路上，希望能与大家共勉共进。