服务器端设计的思想、方法及应用

服务器端设计的思想、方法及应用

当遇到一个业务需求时：

要先了解使用场景是什么样子？

需要提供哪些字段，怎么组织存放它们？

要提供哪些查询功能？

以后是否需要更多的扩展字段？

查询的qps预估是多少？

是否需要关联其他业务的数据？

有没有联合其他数据的复杂查询场景？

用以上问题来决定：

是用mysql还是Hbase?

是用单表还是多表？

是用缓存还是直接查库？

是用Redis还是用MemCache还是用其他NOSql数据库？

是引入Opensearch还是分库分表键就能满足查询需求？

然后再考虑：

是否需要考虑多地机房部署？

在变更很频繁和不频繁的两种场景下，多地机房的数据同步的一致性如何保证？

多地机房缓存的一致性同步怎样解决？

如果使用了异步消息，应该如何设计多地机房的消费情况，是同时消费还是某地单一消费？

－－－ －－－

一个业务的实现方案不止一个，各有各的优点，怎样衡量和选择呢？

如何做对现有业务的改动量最少？

如何做使未来业务扩展性更好？

如何做可以支撑未来可以预期的大流量？

如何做可以在现有资源现有时间内提交一个比较合理的方案？

无论怎么抉择，都要想清楚现阶段下未来一两年内我们能达到的最优架构方案是什么？一旦有了这个方向，所有现在的设计都要向最终的这个方案靠拢。

业务在发展，人也在进步，架构也会不断调整演进，好的架构是不断随着业务发展而演进出来的，不可能在最开始的时候定下来，所以，拥抱变化是架构师必备的技能，一两年内的最优架构也需定时review确保方向正确。

－－－

同时作为架构设计人员，知识面一定要广阔，不断了解学习评估业界的各种技术，做到知晓哪些技术适用于哪些场景。自己提出的方案有什么样的局限，未来可能遇到哪些业务和性能上的挑战，那时具体的解决方案的方向是什么？成本大概有多大？

现实中，最怕一个人学了一个新技术，就想在所有业务上都实践一把，变成了一个手里拿着大锤，看什么都是螺丝刀的人。

同时，优化别人的代码 或要统一若干接口之前，一定要先搞明白为什么会有这样的代码和这么多的接口，知其所以然是必做的一个调研。

－－－

GOF的《设计模式》和MF的《重构》是怎么强调也不为过的两本书，每隔一段时间，翻出来温故而知新是极好的习惯。

－－－

跑题一下，以下两个方面在业务开发中也是非常重要的事情：

1.在整个团队，不同应用的开发过程中，制定开发规范是非常重要的事情，比如哪些层次（Application,Service, Repository）做什么事情，统一错误的返回方案是什么，大家需要遵守的开发规范是如何。

2.设计和开发人员不可盲目遵守产品经理（PD）的需求，要有自己的业务思考，和PD充分沟通讨论后再进行设计开发实现。拒绝做无脑的编码人员。

－－－

谢谢观看讨论。 :D