【杂谈】对代码的一些建议：从单模块到多模块

对于产品，一般来讲，从单模块，到负载均衡的多模块，最后到有服务治理的规模化集群（例如微服务），逐步发展和演进。本文并不打算涉及框架或者架构，也不讲什么大道理，仅从代码编写的角度，看看开发人员需要注意什么。

单模块开发的一些注意事项

单模块并不是指单体方式，根据功能进行模块划分，每个模块在生产环境中是单模块运行（主备方式）。单模块阶段开发人员仍是有要求，在我的实践中，从code review看，经验不足的开发人员会存在以下的疏忽：

一、开发版本、测试版本和生产版本不是同一个版本。What？怎么回事，就是开发人员将配置数据、业务数据（包括log所在路径）都统统打包在一起。

我们以 tomcat 的 war 包为例，一般来讲，开发人员不会将诸如数据库的ip地址、密码、服务提供者的url写入到程序代码中，但是会写入诸如web.xml的配置中，一起打包。这就需要专门为测试环境、生产环境修改配置，重新打包，就有了测试版本，生产版本。但实际上，生产环境的ip地址，账号，密码，开发人员并不需要（也没必要或者不应该）知道，而且一旦生产环境发生变化，都需要返工打包，运维会崩溃的。

有些开发人员会认为，安装了 war 包之后，tomcat 将之解压为文件夹，可以手动修改里面的配置文件。这想法需要扼杀在摇篮当中：

1. 解开的文件夹其实算是个临时文件夹，只要 war 包修改，就会重新解压，也就是，我们需要为每一个版本手动进行配置的重设置，而很多情况下，版本的升级，并不需要修改配置。
2. 很容易出现疏漏，例如进行版本回退的时候，运维人员可能会忘记重新进行配置修改。
3. 只要涉及到手动修改，就无法进行自动化操作，包括自动测试，自动发布，自动部署。当业务发展，我们终要走向devops，手动是无法容忍的
4. 如果采用容器封装，是无法修改的。这限制了系统的容器化和云化。

我们看看linux是如何组织软件包的，程序在/var/lib或者/usr/lib，配置在/etc，log在/var/log下面。这是将业务逻辑（程序)、配置、业务完全独立开来。简单讲就是：代码（逻辑）归代码（逻辑），数据归数据。如果我们混在一起：开发人员开发环境或测试环境的数据，log会污染到生产环境，而生产环境中的业务数据，log很容易因版本升级中出现数据丢失，哪怕是丢失了log，在生产环境中都是运维事故。要养成将逻辑、配置、数据分离的开发好习惯。这种分离，在集群编排部署中尤为重要。

二、缺乏对同一资源并发处理的关注。不要以为单模块就没有并发处理，现在哪个程序不是多线程的。对于刚入行的程序员，比较容易出现下面的问题：

1. 使用静态全局数据传递数据，在并发处理时，这个数据可能会被改写。特别出现在那些开发人员的开发思路仍处于过程开发，还未进化为对象开发时，代码组织相当混乱。
2. 对同一资源，例如数据库，没有考虑如何写保护，采用哪种锁。初入行程序员很多没有意识到这个问题，他们调测是单步调测，跟踪完一个业务请求，OK了就认为都OK了。测试的时候，要加上并发操作同一资源的测试，看看结果是否符合预期。

三、优雅关闭的问题。优雅关闭是在程序结束时，释放程序占用的所有资源，保证正在的处理业务，能够处理完，而不能是处理了一半这种不确定的状态，可以选择拒绝业务，更多的情况是完成业务。

我看过升级时，简单粗暴的直接将tomcat给 kill 掉的，这种方式，如果数据库的事务没有收到commit，这个事务会挂起；又例如 tcp的keepalive在阿土中缺省是2小时，而数据库的连接数是有上限的。还有如果业务执行到一半，可能导致该用户后续业务状态异常而挂起，由于log也被突然中断，出现了问题很难排除。

四、缺乏对异常流程的关注。用户的输入，内部服务提供方或者第三方api的调用，都可能存在意外，开发人员对本模块外的是不信任的，开发世界是性本恶。最简单的，万一web api不是响应200，而是4xx，5xx，你怎么处理。我们在原型中可以不考虑，但是在生产环境中，程序必须以警惕的眼光看待外面的世界。

五、业务逻辑抽象很重要。这是区别你会写几行代码，还是会开发。良好的业务抽象，当业务需求不断增加时，我们可以游刃有余，说不定就只是原来基础抽象的组合，代码具有良好的业务扩展能力。如果不注意抽象，说白了就是我们程序内部的逻辑设计，来一个新的需求，吭呲吭呲地写一堆代码，将其堆叠在原来的代码之上，几个需求后，就是一堆草，代码没法看了。

六、接口名字要清晰表达其准确功能。例如选择接口的名字叫deleteUser，resetUserPolicy，或者resetUserPolicyAndClearUserStock。要给接口函数加上注释。我们不是交一次作业，代码要维护要发展，生命期长着呢，有时开发人员自己都不太记得了。应有写文档写注释的习惯，明确调用的影响。

在某个案例中，开发人员只是想重置用户的某个属性，结果连带将用户的持有物品清单也一并清空。只要是人都会犯错，但是有很多可以通过规范化的开发流程来避免，在这个案例中：

1. 接口调用时，开发人员不清楚这个接口引发的影响，虽然这个接口是他自己以前写的。这可以通过明晰的接口命名以及注释来避免。
2. 调测中，只关心本次新增功能是否实现，没有认真核查对外的影响，包括该用户在数据库完整数据，是否触发了第三方接口的调用，可以通过认真核查log发现。开发人员不能只看log的最后结果，要全部核查是否都符合预期。

横向扩展的多模块

从单模块到多模块，最基础的，就是 AKF 的 X 轴扩展。不要认为 x 轴扩展是自然天成，多部署几个 copy 就可以了。X轴扩展也是有条件的。我们举个例子，某个web网站，用户登录进去后可以进行数据的增删改查，具体业务是什么不重要，以 J2EE spring 为例，是否可以简单部署 n 个模块，在前面加上负载均衡器（LB）就OK了？

没那么简单，当用户登录成功，会分配一个 session 给该用户（浏览器），在后续的访问中，浏览器的 http 请求中会通过 cookie 携带 session id，服务器由此判断用户的合法身份。如果使用最常见的轮询负载均衡，模块 A 收到用户的登录请求，分配了 session，并保存在内存中，用户下一个请求，被路由到模块 B，模块 B 的内存中并没有这个session的ID，由此判断用户无效，重定向到登录页面中。如此，来来回回，这个可怜的用户就在不断地登录成功和重新要求登录中挣扎。

因此，如果不做任何的处理，直接将模块 copy n 份，可能会导致整个业务出现问题。例子的问题就是模块 B 无法获得模块 A 内存中的session信息，要处理，可以沿两个思路：

• 消灭问题
• 解决问题

先看看消灭问题，就是不让问题出现。例子只要确保相同用户，也即相同 session id 的 http 请求能够路由到同一模块即可。这种方式，对代码没有要求，但是对负载均衡器有要求，要求将相同的 session id 的 http 请求路由到同一个上游模块。方式有很多，例如根据 session id 的哈希值取模，也可以作为 proxy，在 session-id 的结尾加上一个上游服务器的标记，等下次 http 到来时，可以根据 session id 得到它以往是哪个上游模块处理的。这种方式虽然对代码没有要求，但是对运维和部署有要求，开发人员应明确指出，以此要求负载均衡器。例如，如果使用 nginx，是否该用openresty，通过 lua 来自定义路由。

如果采用解决问题的方式，就是让 B 模块也能获取 A 模块分配的 session id，也就是 A 模块不能将 session 数据只放在自己的内存中，由于模块可能部署在不同的机器中，因此也不能通过本机共享内存的方式。如果你想到存放在数据库，那么思路方向对了，我们确实要找一个各模块都能访问的地方来存放 session 数据，但是这个不能采用持久化的存储，如数据库。很简单，这就不是一个持久化的数据，这是临时的，会变化的数据，不需要也不应该存放在数据库。如果放在数据库，会加重数据库的读写压力。这时高速缓存，例如 redis，memcached 的就是比较合适的选择。由于引入了高速缓存，系统的架构就出现了变化，对代码就有要求，本地内存读写变为高速缓存的读写。

由此可见，横向的 x 轴的扩展绝不是简单将模块copy几份，前面加个负载均衡就可以。有了多模块，跟着会有很多新的问题，例如服务发现、全链条跟踪等，这些就是微服务的事情了。