传统软件企业向互联网企业的转型

2005年我提出将公司CRM产品向SaaS化发展的战略时，很多人都认为那是一个巨大的冒险，而如今已经没有人再质疑传统软件向SaaS化发展的趋势。很多决心向互联网产品转型的企业，都会遇到这样一个问题，传统的项目化的业务模式利润越来越薄，而投向互联网的产品又屡屡碰壁，不是产品迟迟无法成型，就是资金烧不起。怎样才能顺利的完成这样的转化，本文将在这方面进行探索。

三大误区

近些年互联网在商业上的巨大成功，特别是这几年移动互联网的迅猛发展，许多新的产品和新的企业骤然崛起，在墙外的人们总不自觉的看着成功企业靓丽的光环，并误以为那就是其本质。我常见到的误区有三个：互联网必须烧钱、要先明确盈利模式、沉迷于新技术和新概念。这一章节，我们对这些想法一一抽丝剥茧。

误区一：烧钱就是互联网

近十年互联网企业的烧钱模式是深入人心，可烧钱的背后是什么呢们先看一看烧钱成功的案例。

首先是京东，众人皆知京东持续亏损，直到2017年才真正实现盈利，但这是不是烧钱模式呢们来看看下图。

技术转型三步走

完成这些代码，我们可以看到以下的界面：

如果没有配置映射字典，那么配置文件要稍微增加一句，变为：

可以看到，不仅可以按字段进行过滤，还包含了分页。这就是模块化架构相比单体架构的一个重要优势：开发效率更高。但不可否认，完成这样的查询模块也是有代价的，它需要为模块的开发投入工作量，但只要是可以重复使用的场景，模块化都是非常值得的，因为随着在今后的使用功能越来越多，边际成本将越来越低。

除了开发效率更高，模块化另一个重要作用是功能扩展成本低。例如，在上面的查询基础上，产品经理提出要加入实时统计的功能，如果还是传统的模式，必然导致需要重构该功能点，而模块化之后，不需要任何改变，就可以得到：

左边的模块化架构，虽然已经在控件内部做了功能切分，但是新增ES执行组件（橙色）后，查询控件需要重新打包代码后部署上线，由于控件是作为一个整体部署在一个应用容器中，新增组件的严重BUG将有可能导致整个控件的崩溃。

右边的微服务架构，原有的查询服务、SQL服务与新增的ES服务（橙色）是三个独立的小系统，分别部署在不同的应用容器中，此时若ES服务内部出现BUG，只会导致ES服务的崩溃，这一分离的架构将新的服务引发的问题与原有服务隔绝开，而不会影响原有应用的正常运行。不仅如此，相比较整个查询控件的重新测试和部署，测试和部署一个微服务的速度要快得多，这正符合互联网产品的需要。

但微服务架构不是软件行业的银弹，带来了好处的同时，也会带来一些问题：

一、测试难度增加，必须用自动化测试来替代传统的手工测试。因为微服务对外的接口只是Service API，而不是用户可以看到的界面，如果没有编写自动化测试脚本的能力，微服务的测试无从开展。

二、运维难度增加。从原来只需要管理一个系统，变为管理多个微服务的子系统，多个微服务之间也需要用配置文件将他们连接起来，这种网状的结构，随着微服务的数量增加，其运维工作的复杂度将几何级数的增长。传统的开发人员打包程序，交给运维工程师去手动部署上线的运维方式已经无法适应微服务架构，正因为如此，“谁开发谁运行（You build it, you run it）”的DevOps理念开始流行。

三、监控难度增加。每个微服务就是一个子系统，都运行在一个应用容器之上，每个容器都有自身的服务状态、接口调用情况、异常告警等诸多信息，监控的复杂度成倍增长。正因为这一特点，互联网的SaaS产品可以用微服务架构，但部署在客户服务器或私有云上的传统软件产品就很难采取微服务架构，因为这对集中监控有很高的要求。但后续篇章我们会谈到，Docker这一事物或许将改变这一问题，并带来新的可能性。

微服务架构是现在最适合互联网产品的一种技术架构，但不代表传统软件企业就可以直接拿过来使用。在技术方面，如果你的自动化测试、自动化运维和监控没有达到要求，微服务架构只会给你增加工作量；在管理方面，如果你还是传统的开发流程和组织架构，做不到向DevOps的方向靠拢，无法适应小版本快迭代的要求，微服务架构同样会给你带来很多的混乱。

第一步：模块化架构

模块化的架构，不仅仅适用于互联网产品，对于一些还处于单体架构阶段的传统软件企业，应首先向模块化架构转型。在实践过程中有几点心得：

一、敢想敢做。在事务性的工作压力面前，由于对模块化额外工作量的担忧，企业的技术管理者们常常会在第一步就停滞不前，设想的多，但迟迟不动手。实际上只要在实际工作中有共性的，可重复性的功能集合，都可以考虑模块化的思路将他们整合为一个模块。

二、从小到大。模块化设计的时候，人们常常会想的太多，希望一次解决所有想到的问题，使得一开始的复杂度就很高。过高的期望，过于复杂的设想，会导致模块化的工作量太大，这导致要么畏惧工作量而中止工作，要么周期过长而最终出来的产品事与愿违。在我们的实践中，好的模块第一版的开发工作都会控制在两周的时间，这样尽快上线一个版本，然后交给其他团队去使用，在使用的过程中收集意见，不断迭代新的功能，往往比一开始就设计很周全的效果好的多。

三、眼界宽广。开源组织的发展已经很多年了，各种开源工具和产品层出不穷，多关注开源社区的发展，多看看别人的项目，不仅可以扩展自己的思路，还常常可以找到合适的项目加以改造和重新组合后，成为适合自己企业的模块。

四、包容失败。模块化之路有成功，也可能有失败，如果遇到失败的情况，应当检讨事情哪些做的不好，也可以检讨人选哪里选的不对，但不能遇到失败就放弃模块化的道路。

五、临时组建。有些企业在一开始就会组建专业化的组织（如架构组、控件组等）去专心开发模块，但这样做会很容易使他们与业务工作分离，成员逐渐脱离生产的实际需要，出现闭门造车的问题。事实上应该是在实际的开发工作中发掘出模块化的功能需求，这时应当有少数的几个人临时组建一个开发组，快速开发出来，然后推广使用。如果一个模块功能越来越复杂，平时维护和升级的工作量都很大，那么可以针对这一个模块成立固定的开发组，专门负责它的开发工作。从生产实践中寻找模块化的需求，会比成立只负责模块开发的专业组的效率更高，开发出来的产品也更能符合业务的需要。

第二步：敏捷型组织

技术的转型不仅仅是架构的问题，还是组织形式的问题和开发流程的问题。敏捷开发模式不仅仅适用于微服务架构的技术体系，也可以为传统产品的开发提供帮助。组织的敏捷化主要体现四方面：

一、小版本快迭代，不要试图一次开发一个大版本，一个版本的开发周期应当尽可能的缩短。

二、测试驱动开发（TDD），TDD不是说产品不需要思考和设计就直接开始构建测试代码，而是将需求分解为任务列表，再从列表中挑选一批任务，转换为一组测试用例，然后不断循环去实现。

三、持续集成持续交付，不要试图在版本的末期才提交整套代码，而应当至少每天实现一次构建和集成，充分利用测试用例的覆盖，在代码提交的当时就立刻发现问题解决问题。

四、开发与运营的紧密结合，打破传统项目型企业中开发、QA、运维、运营之间各部门的鸿沟，建立以业务为主线的整套协作流程。

第三步：微服务架构

当你的技术人员适应了模块化的思维方式，当你的组织与开发流程进行了敏捷化的改造了，更重要的是当你的产品逐渐往互联网发展了，你一定会自然而然的产生向微服务架构的体系转型的冲动。这时可以着手在五个方面进行准备：

一、业务拆分，体现在设计环节：在设计的时候，要有足够的判断力来合理的规划服务之间的界限。

二、服务治理，底层技术的支持：首先要选一款适合自己实际情况的分布式服务基础框架，对于服务的发现、治理、熔断、降级，都要做好相应的技术准备。

三、自动化测试用例高度覆盖：微服务架构一个明显的变化就是随着服务的增多，测试的复杂度显著增加。如果继续沿用传统的测试模式就会遇到瓶颈，为了保证高效的迭代，尽量做到更多的环节实现自动化。

四、自动运维 ：微服务拆分之后，每个服务都可以独立部署，进而言之应该是随时随地可以升级。尤其当互联网发展到今天，业务要保持对市场变化的一个高效响应，自动化运维就是提升交付速度的一个重要环节。

五、监控：包括硬件环境、服务状态、系统健康度、接口调用情况、异常的实时告警以及潜在问题的事先预警等等。监控在实施微服务过程中会重要到什么程度呢/span>一句话：没准备好监控，就不要搞微服务架构。

没有什么事情是一撮而就的，微服务的架构也不是一步就能全面实施的，在工作中有规划的推进，逐步的准备，微服务架构的建设也就顺理成章完成了。

三点注意

第一点：要注意从传统项目孵化互联网产品的思想

很多时候企业会得到一些看起来与市面上互联网产品类似的项目，于是乎决策者们就开始设想完成这个项目后顺带孵化出一款互联网的产品，我就曾经在工作中遇到这样的事情，这样的思维逻辑下会产生以下三个无法调和的矛盾。

首先项目与互联网产品的迭代方式不同，项目通常以交付工期作为迭代周期，而互联网产品要求快发布快验证。如果项目里面也采取互联网产品的快发布快验证，项目的最终客户会有耐心去帮你审核半成品吗/span>

其次项目与互联网产品的目标不同，我之前就遇到过的希望通过运营商的用户感知体验的项目孵化出APM产品，而运营商侧重的是终端用户的测试结果，而APM的目标群体是各ICP，而ICP更侧重的是结合终端用户的测试结果查看服务器端的运行问题。这不同的客户群体不同的产品目的，两个产品的需求和体验截然不同，甚至应当是完全不同的产品。

最后是项目与互联网产品的管理模式不同，不同的管理模式就意味着不同的考核办法，考核办法又间接影响开发人员的思想。当你想做好项目时，它离互联网产品的体验就越来越远；当你想更符合互联网产品的体验时，项目的范围和工期将不可控。鱼与熊掌不可兼得也。

或许这时候有人会问，那我开发完项目之后，有了一定的技术经验再去开发互联网产品不是就可以了吗先我们在上面就指出项目与互联网产品可以说是两个南辕北辙的事物，重新再开发互联网的产品并不一定能规避什么技术风险，反而因为原来项目的惯性思维可能会固化你的思路。这样又不省钱又固化思维的事情，做起来又有什么意义呢/span>

第二点：要注意大而全的闭门造车的思想

一个产品如果初期版本设计太过庞大，就很容易陷入闭门造车的怪圈，因为你无法最快速的获得运营数据，也无法与客户有效的进行交流，获取真实的体验和需求。只能采取闷头瞎想，下意识或者自动忽略对于产品基本需求的科学性调研，只是单方面地认为某个群体有某种需求。

产品上线后，也要避免不自觉地虚拟出用户的需求或者片面扩大用户的需求。不要去主观想，不要去替用户考虑，要做的只是访谈，有引导的焦点会议，有导向性的用户研讨会，设计思路清晰的调查问卷，同时要在产品中采集实际的运营数据，学习结合实际数据去分析用户的需求。

第三点：要注意生搬硬套沿用传统项目的KPI考核模式

传统项目的考核总是避不开利润计算、工作效率、责任归属等指标的划分，而这种呆板的考核模式并不符合互联网产品的思维。互联网产品强调快速上线、快速试错，出了问题快速决策，集体负责，根本没有时间给你划分责任的归属问题，自然也无法很有效的用KPI去计算工作效率，互联网产品的特性则更加难以计算一个开发周期的利润指标。

未来的可能

随着微服务架构与基于容器的虚拟化（Docker为代表）的发展，未来十年的软件行业会产生非常大的变化，应用将由各种微服务组合而成，软件开发领域将划分为两类人群，一类是微服务的开发者，另一类是微服务的组装者。软件应用的开发将越来越像现代工业产品的开发模式：零部件的开发与产品的组装。微服务的开发者专注于单一微服务功能的实现；微服务的组装者关注如何将已有的微服务组装起来成为客户需要

来源：砯崖