架构师如何帮助初创企业高效和低耗？

之前的文章中我们有说到过对于参与人员少、功能复杂度低、开发周期短的初创型企业在做项目时推荐采用市面上主流的技术框架做单工程开发。这种方式不仅开发效率高，人员专业技能要求也不高，好招人，运维成本低等等，优点是一大堆。就没有缺点吗？当然有，大家在同一个工程里写代码，你这边写个变量，我那边加个类，这边我调你一下，那边你调我一下，不仅代码耦合度高且混乱，到最后可能仅仅对某个模块做了小小的改动导致其它地方出现一堆问题。测试成本、维护成本也越来越高，甚至最后变的不可维护。再有诸如打包编译发布的过程越来越复杂，出错几率越来越高，任何一个模块的技术问题就有可能导致整个应用宕机瘫痪等等各种问题，这里就不一一说明了。

因此我们在一开始做技术规划时就需要识别到单工程所带来的风险以及应对方案。比如，第一阶段可以业务为单位分模块开发，也就是所谓的单工程多模块。这样做的好处是大家还是在同一个大工程里写代码，不同的是业务代码有了清晰的边界，开发中自然就会克制许多。另一方面，模块的设计也为以后的架构演进做好了前期工作。单工程多模块结构如图：

如果企业能够顺利渡过第一个阶段（价值论证），那么接下来业务将进入快速迭代发展期，广阔美好的前景将帮助企业吸引到资本的进入。有钱了必然加大资源投入，从而促使业务更加快速，因此团队也会快速壮大（我很幸运经历了蘑菇街发展最快速的阶段，那时每天都能看到大量新同学的加入，到处洋溢着热情陌生的面孔）。团队大了，人多了我们上面讲到的单工程的问题就暴露出来。如果 CTO 或架构师够有经验，必定会根据企业经营、业务发展、团队规模等情况，提前对架构进行演化。做到业务发展的同时，逐步调整架构。即不影业务发展，又不会增加工作量和资源的投入。

单工程多模块的系统可逐步将热点模块提为工程，分布在多台或同一台服务器上（具体看业务量），如图：

图中的工程是由最初单工程的模块演进而来。因为模块是以业务纬度进行抽象，如果抽象逻辑做的比较好，在做工程分离时相对就会比较轻松，通过代理模式将被调用的方法代理为远程方法（RPC）即可。因时各业务内部逻辑的改动仅需修改对应的工程代码，并不会影响其它的工程（除非远程方法入参或出参被改动），各团队或开发人员只需保证自己工程的正确性和合理性即可。当然在条件允许的情况下，仍然可以对分离出的工程做多模块的设计。如图：

简单介绍一下远程方法调用。工程分离后成为了多个进程被部属在同一或不同的服务器上，原本一个进程中处理的请求变为由多个不同服务器上的进程相互协作完成。比如有三个工程：电商系统、订单中心、交易中心。用户发启支付请求后，首先请求会经过电商系统校验商品信息，再经过订单中心生成订单，最后到交易中心完成下单支付。同一个业务由不同的工程相互协作完成（SOA（面向服务的架构）），也就意味着工程与工程之间需要相互调用和通信，这时候技术负责人要面临技术选型问题，即用多大的成本来实现这个目标？这个问题还是得要结合自身实际情况来考量了，这里给出两个建议：Http：利用 Http 作为工程间通信的手段，不仅使用起来简单，还非常稳定可靠。市场上有大量的开源 SDK 对其都有很好的支持。性能方面虽然 Http 包含了一些头信息占用了部分资源，但对于初创公司的并发规模来说，完全可以忽略不计。另一方面 Http 1.1 中默认开启了短暂的长连接（Connection: Keep-alive，Keep-Alive: timeout=20），即：数据传输完成后仍然保持 TCP 连接不断开（不发RST包、不四次握手），对于用来做工程间数据的传输无疑在性能上有了质的改变。再有一些第三方工具内部实现了 Http 连接池（如：HttpClientPool），使其在性能上得到了较大的提升。不足之处是开发时较为繁琐，不如 RPC（Remote Procedure Call Protocol —— 远程过程调用协议） 用起来简洁。

Hessian：轻量级的 RPC 工具，其底层采用了 Http 协议，相比直接使用 Http 或 WebService，Hessian的好处是精简高效，可以跨语言使用，而且协议规范公开，我们可以针对任意语言开发对其协议的实现。目前已有实现的语言有：java, c++, .net, python, Ruby。另外，Hessian与Web服务器结合非常好，借助Web服务器的功能，在处理大量用户并发访问时会有很大优势，在资源分配，线程排队，异常处理等方面都可以由成熟的Web服务器保证。

这样的架构是可以循环扩展的，当技术团队突破50人时，服务治理、数据安全、持续集成、系统性能等就是要重点考虑的问题。这方面成熟的解决方案有很多就不一一赘述了。

帮助企业活下去，活的好是每一位架构师第一要责。