如何做技术设计

2016-09-18 09:41:00

做业务的开发们，几乎都有一个做架构的心，好的业务开发者不仅要能做好业务，更要能做好业务架构。在现实中我们总会遇到大大小小的需求，那我们应该怎么在满足业务的同时又能作出很好的技术设计呢。

1. 什么是好的技术设计

好的技术设计应该很清楚的表达了：

要解决的问题
解决方法
各种解决方案的优缺点对比
如何实施

2. 要解决的问题

要解决的问题，其实就是需求是什么。很多人觉得提需求是产品经理的事情，和开发没有什么关系，开发人员只要写代码就可以了，实则不然。产品经理提出的需求和开发清楚理解要解决的问题，还是有一段距离的。

最简单的产品经理提出需求：为用户提供一个登录界面，可以在APP和微信上使用，同时能够防止机器人自动注册。

2.1 拆解产品需求

说到产品需求，就想起很多网上和工作中遇到的同事在吐槽产品经理，几乎都是在吐槽产品经理奇葩的需求和混乱的逻辑。我觉得出现这种需求却能进入开发阶段，作为开发人员也是有责任的。

我一直任务开发人员是要参与到产品需求中去的，这个在程序员的业务观中也有详细的阐述，这些是题外话。

一般产品经理提出的需求在技术人员来看都缺少足够的细节，这种时候需要针对产品需求进行拆解，将需求拆解为更小的需求，确认其中的细节。例如针对登录界面的需求就可以划分为用户登录界面的基本逻辑和防机器人自动登录/注册的两个子需求。

2.2 挖掘潜在需求

针对上面的两个子需求，我们继续探究一下其中的潜在需求：

用户登录基面的正常逻辑里面需要确认界面应该是什么样，在不同平台上的样式有哪些差异。是否提供微信登录、微博登录、和qq登录等第三方登录平台的登录。
防机器人：使用何种方式防止机器人自动登录和注册，使用验证码还是使用短信验证码，不同验证码方式有哪些样式需求。

这其中的很多细节都是隐含的，有些是产品经理自己能想到的，有些是产品经理模糊有个印象的，有些可能压根就没有想到的，这时候需要技术人员一一确认细节，补充丰富需求。

2.3 未来可能扩展的需求

针对用户登录这个需求，未来可能需要，在用户登录的时候将用户的登录上下文参数记录下来，如用户登录ip、登录平台、微信登录时的id信息等，并将这些作为用户的特征信息记录下来并广播出去，供其他业务模块做逻辑判断的条件之一。

比如，未来可能针对微信端登录的用户，给这部分用户发抵用券等行为。

2.4 确定需求

拆解并细化了产品需求，但并不是所有的需求都要在这一次实现，需要最后跟产品确认这一次需要实现的需求。

确定需求的过程时常成为和产品经理PK的过程，在PK的过程中最重要的是产品的价值和实现的成本，在这两方面获得一个平衡。以这个需求为例，微博登录相比微信登录就不是一个很有价值的需求，针对这种需求如果时间太紧就可以PK掉了。

确认了需求，我们的技术设计也就完成了一半。这样说来一些技术人员可能会觉得有些夸张，但实际工作中，不同的需求真的可能完全改变技术方案，——比如在关于微信的一点思考文中，提到Slack和微信关于聊天记录的不同而导致技术上实现成本大增，且实现重点都会发生很大的变化。

为了便于后面讨论，我们例子中的产品需求定位下来只提供用户登录，和短信验证码验证。

3. 解决方案

3.1 业务领域的划分

现在的技术大趋势是采用服务化的方式实现业务，正确划分业务领域也是实现服务化基础之一。

现在微服务的概念越来越火，服务按照什么维度划分才算是“微”，到现在还没有什么标准，不同的实践会有适合自己的划分方式；按照业务领域划分服务，可以保证一个服务能够提供一个业务领域的支持，更利于业务管理和服务规划。同时微服务也是一种运维概念，将每个微服务单独部署，但这种方式会导致机器很多，对运维是一个巨大挑战，在遇到线上问题时也是一种巨大的挑战。因此按照业务领域来组织更细粒度的服务，如订单项目中包含创建订单服务、订单查询服务和订单修改服务等，做统一发布管理。

业务领域划分，首先需要从需求角度来分析。如例子中的需求主要包含用户登录和短信验证码两个方式。

从业务角度来看，其使用场景是用户，从使用场景来说更适合在用户服务上，细分下来可以划分到用户登录服务；短信验证码在这个需求的使用场景，面向对象也是普通用户，在这个需求里来看，划分到用户服务领域没有什么大的问题。
但是长远来看，短信验证功能不仅仅会用在用户登录，也可以用在商户登录、用户注册、用户修改密码、用户领券验证等场景，面向的对象也不单单是普通用户，可能有商户等等。因此长远来看短信验证划归到用户服务里是不合适的。
划分业务领域，不单单要从业务角度，还要从系统规划角度来分析：
例如这里的短信验证服务，因为会出现多个复用的场景，且其业务领域更偏重于验证，因此将验证服务与用户登录服务独立，使用服务调用的方式来实现复用，更便于以后的系统发展。

实际项目中划分业务领域不会像例子中那么界线分明，项目中的业务领域相互有包含关系，业务边界有交叉甚至有相似之处，但从业务和系统的角度深入分析，才能慢慢厘清其中的关系。

3.2 数据模型

业务领域模型和数据模型共同构成了系统业务模型。数据模型是数据库系统的核心和基础，在设计中使用 E-R的方式来展示数据模型。

业务模型抽象出来之后，我们的数据库表的设计也就基本有出来了，只要再根据业务需求进行合理的字段冗余和索引设计就形成了基本的数据表。为了应对高并发需求，数据库会进行分库分表的处理；前文说道的业务领域划分，在数据表上就是垂直分表的体现。不过数据库的分库分表是一个很复杂的话题，可以参照分库分表的几种常见形式以及可能遇到的难题。

3.3 服务关系

厘清了业务领域和业务模型，各服务之间的依赖关系也就非常清晰了。在本文的例子里，用户登录服务直接依赖短信验证服务。在技术设计中，不单单需要厘清本次需求涉及到的服务相互关系，还需要理出受影响服务的关系，避免因为新增业务而打乱服务之间的关系。

服务模式在我们需要什么样的微服务中有更详细的阐述。

3.3 接口设计

关于api设计文章已经太多了，比如 api杂谈、 RESTful API 设计指南和 RESTful API 设计最佳实践，都已经比较好的介绍了api设计时需要注意到的问题。

但是在技术设计中，接口设计应该是自然而言的过程，很多时候api设计也并不一定是必须的；真正在实施过程中，api的定义不可避免的会出现微调。

几个api设计的坑点：

提供适当的批量查询接口。比如批量查询用户信息等这种基础性的查询。
服务在接口层有自我保护。如批量查询接口，需要控制批量查询的规模，过大规模的查询不单单会对自身系统造成很大的压力，在数据传输过程中也会大量占用网络带宽。
api根据使用业务场景分类。比如现在电商中时常使用的立减，在展示测的立减展示服务和在支付时的使用立减服务，就是两个不同的使用场景。不同的使用场景对服务的要求是完全不一样的，立减展示更多偏重于信息展示，同样是要请求立减金额，在实现上可以使用缓存，也能容忍一定程度的数据金额不一致；但在立减使用场景下，在请求立减金额时却需要严格的校验使用规则，且需要获取实时的立减金额。

3.4 业务流程Demo

到此为止，系统的整体已经完成了，这时候应该已经能够满足业务需求了，可以根据实际中的业务流程来实验一下我们的系统了。

业务流程demo可以采用UML时序图的方式来检验，系统中每个流程跑下来，就可以看到对每个接口的调用情况和对数据库的访问情况。

4. 实施方案

有了业务系统设计，剩下的就是要怎么实施了。实施中会牵涉到参与开发人员、具体的时间节点已经模块划分等，这些和每个开发团队自身情况非常相关，在这里不再多说。这里主要说说系统的上线方案和回滚方案。

上线方案
系统如何上线？如果只是新项目上线，那只要按照项目依赖关系依次上线就可以了。但如果涉及到老接口的修改和在线数据模型的修改，就会牵涉到新旧逻辑兼容的问题。灰度上线，需要考虑到新数据旧流程、新数据新流程、旧数据旧流程和旧数据新流程的业务逻辑。
回滚方案
回滚是上线的逆流程，针对新系统上线的回滚中，只需要关闭入口、没有新数据进入就可以按照上线顺序逆序依次回滚。但针对老接口修改和在线数据模型修改时，同样需要考虑新数据旧流程、新数据新流程、旧数据旧流程和旧数据新流程的业务逻辑。

关键字：产品经理

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击举报进行投诉反馈！