架构演化的思路

最近我们在讨论B端和C端的整体架构，收获不少，本文就共性的东西总结一下，指导后面其他架构的演化。

相信我们都听过这句话，评价一个架构的好坏，一定要讨论背后所支撑的业务；而业务并不是一开始就是这个样子，业务是一天天累积扩大的，那么架构也应该是逐渐演化的。那如何让架构进行演化呢？

经过我们几轮的讨论，我觉得可以抽取的一个模式如下图：

从一线开发，到架构设计，上线，再到一线开发进行验证，形成一个有效的闭环，推动整体架构的逐渐演化。

一个好的架构一定不要凭空去想，在纸上画出的架构会有下面的问题：

所以，进行架构的第一步应该踏踏实实的，召集一线的开发，听取他们的反馈，收集他们在日常的开发中遇到的问题。讨论的时候可以聚焦到下面几个方向：

基本上，这个环境就是让开发主动说一些实际的问题，不过不要忘了稳定性方面的工作。

听完开发的问题，可以组织进行一个小范围内的讨论，将问题归类，然后，找出一个大概的方向。当问题讨论清楚后，方向其实比较好找，比如：

这个地方需要注意的是，方向性的问题一定要一定范围内找人讨论，避免出现下面的问题：

不跟别人讨论，一个人闷头苦想。因为一个人的力量比较有限，或者当时就是忽略了某个点导致方向选择错误，所以一定要拉几个人，特别是相关模块的owner，一起看看想想；
拉太多的人讨论，结果很难形成结论。这个阶段重要的是要确定方向，所以避免又回到一堆人“发牢骚”的场景。

有了方向，接下来就是具体方案设计。方案设计的时候，要考虑清楚下面几点：

方案落地后，不要忘了再找一线的开发手机反馈，验证一下当初第一步收集的问题是否解决了，是否有新的问题，或者问题解决的不彻底。这个地方要注意的是：

另外要考虑的一个因素就是时间因素，因为，业务有的时候领先于先于架构：比如一些纯业务系统，只有业务慢慢上去问题才会暴漏，然后为了避免更多问题的出现我们开始优化架构；而有的场景，比如，稳定性，性能等，架构要优于业务提前考虑（至少提前一个季度），避免业务上去之后系统扛不住。

架构里面经常的面临的问题就是分分合合：有的模块过于庞大需要拆解，有的模块过于简单需要合并，基本上，我们在考虑设计的时候会按照下面的模式思考系统划分：

系统词：这个时候是单体应用阶段，或者最初的大而全的系统，基本上按照明显的系统划分，比如，订单系统，交易系统等等
业务名词：当系统膨大到我们都觉得需要拆分的时候，接下来就开始按照业务名词拆分了，这个时候，这些业务是原来大而全的业务的一个子集，例如，订单系统的评价，店铺系统的详情页面，这种拆分有利于简化原来系统的逻辑，进一步专注于个别的业务流程
抽象名词：当一些明显的业务子集被抽取后，往往还是发现系统过于庞大，比如：发布集中到一部分代码，或者每次发布都受制于某一部分逻辑，这个时候，就要发现业务名词之外的东西了：抽象逻辑。抽象逻辑比较隐蔽，不像业务名词那么好发现，但是，一旦挖掘出来，往往对系统的架构有很好的调整，例如，人员管理系统的酬薪计算模块，工单系统的派单模块，这些都是将抽象的逻辑进行细化和剥离，实现整个系统的优化。

这次讨论给我一个特别的提示就是，B端系统和C端系统的技术方向上有一个显著的区别，这个区别指导着我们怎么去做B端和C端的技术规划：

最近面试了一堆人，基本都C端小伙伴，这个时候面试的思路就是怎么解决一些技术难点，怎么保障线上稳定性，其中有几个是一直做B端的，面试的时候对于性能稳定性了解的明显不够，当时就想：那应该怎么去面试B端的同学呢？

经过这次讨论，突然觉得做B的业务就是要解决效率问题：

效率对B端而已，就跟稳定性对于C端一样，都是时刻都要关注的，例如，我们是做单车的，那么，作为B端的小伙伴就要解决：

这样以来，B端的技术方向和考核点就会比较清楚。

在讨论架构的时候，渐渐的理清楚了团队的技术发展规划，以前做中间件的时候思考了一部分，现在更加完善了一下：

基本上，按照时间和团队规模进行演化：

当然，并不是严格按照时间先后进行演化，不过基本上在做规划做设计的时候，都要考虑目前团队处于哪一个阶段，团队成员处于哪一个阶段。