微服务和组织该如何搭配？

　　在设计系统技术架构的时候，我会思考，这个技术架构能给企业或者市场带来什么价值，技术架构能像其余产品那样卖钱吗？我也常常会听到相似于“这个架构很牛X”，“这个架构很先进”以及“这个架构能抗万级并发”这样的评价，再回到市场角度想一想，这个“牛X”或者“先进”有哪一个老板真正愿意买单？“能顶住千万级并发”是否是每一个企业的核心需求？多年的工做经验告诉我：绝地有，且不在少数。

 

　　多年下来吧，找上门的客户不少都是十万火急地想找一个牛X、先进和稳定的技术架构，有一些并非什么互联网公司或科技企业，但他们的信息化建设问题已经严重影响了企业的核心业务，甚至这个问题已经上升到了他们企业最顶层的紧急事务。缘由并非他们没有技术团队作支撑，而是由于他们使用了所谓“牛X且先进”的技术架构，而被迫让“技术架构”成为企业当前的“核心需求”。

 

　　 “我据说微服务架构很先进，大家公司正好有这样一个研发框架，并且还有千万级用户和上万级并发量支撑的案例验证过了，可否卖给咱们”。我很能理解他们的困境，但曹老板说过：“作人要真诚和蔼良”。因此，我很诚恳地表达了简单地买套代码是没有什么效果的，甚至还有可能变本加厉，最终用很差，砸坏的但是我本身的招牌。

 

　　这些领导或企业管理者对微服务架构的渴望无非就是对提升企业竞争力利益最大化的渴望。处于这样一个信息化时代，就算企业没有“互联网”或“科技”字眼，但他们始终都离不开信息化建设这个基石，由于信息数据化的优点太大了。因此，从市场角度看，一个好的技术架构真正能给企业带来的核心价值是“增效降本”。再结合前面的问题，“牛X”和“先进”是否是等同于“增效降本”？这个问题留给你们去践行思考了。有的企业声称本身使用了大型互联网公司级别的技术架构，但到头来成本却愈来愈高。据我对他们的了解，缘由不少，但最为突出和迫切的，仍是他们缺乏一个与之匹配的技术组织架构，这是他们没能真正“牛X”起来的直接缘由。

 

　　做为一个“增效将本”的企业内部组织，首先，最基本要确保的是给企业所带来的价值必须大于自身组织的投入成本，这也应该是技术员工最基本的价值观念。但能真正遇到具有这种价值观的技术人员很少，他们更多地是埋头对“牛X技术”的追求，忘记了技术的本质。其实，这个现象跟目前的行业状态有关，那些什么“青春饭”、“35岁危机论”等迫使他们必须在短期内赚取足够的金钱，而IT行业最能赚钱的手段就是跳槽，而跳槽最容易涨身价的就是保持本身拥有“牛X”的技术。因此他们内心不会想太多如何帮助本身当前所在的这个企业能赚多少钱，更可能是借助在这个企业的短暂时光练练本身牛X的技术技能。因此不少应聘者都会问“大家公司用的是什么技术”而不是问“大家是如何经过技术手段去帮助公司增效降本”。以上所描述的技术人员不限于技术高管，因此企业很难有一个稳健且可持续发展的技术架构以及组织规范。

 

　　仗着互联网趋势，技术组织不少时候都自觉得是“大爷”级别的，但技术组织自己是一种成本投资，技术组织存在价值的公式很简单：技术价值=为企业总体利益的增效-自身技术组织的成本。技术能增效，主要仍是根据企业价值链结合业务架构和技术架构的搭配去提升企业自身的市场竞争力，因此如今不少企业会有业务架构师一说。而技术组织的成本控制不在于本身使用了多牛X的技术，仍是那句老话：要发展，先自知，没有最好，只有最合适，作人作企业亦是如此。

 

　　以本身所在公司为例，从2011年5月我还没正式毕业就进入公司接手技术管理以来，一切都是从零开始。随着移动互联网的发展趋势，迫使咱们必须进行架构改造，从2014年开始咱们进入“服务化V1.0”模式，也就是咱们如今微服务架构的前身。这些技术发展史都能从我之前的文字中找到，但对于咱们自身组织的描述得很少，但技术架构自己不会独立存在，跟组织架构仍是有很密切相关，因此，我以为仍是有必要介绍一下。这仅仅只是一个经验分享，并不表明咱们就是成功的榜样或标准。

 

● 技术员工

　　从上图的技术与组织架构对比能够知道，组织技术员工比如技术的物理服务器，都是架构的基建，一个员工的品质比如服务器的质量，并非说有了上层对基础资源的统一管理，淡化了每个独立个体的重要性就不表明不须要好的员工或服务器了。固然，好的东西都贵，但性价比高的仍是值得不断去追求的。

 

● 技术部门

　　技术部门比如LaaS，是对全部独立个体的统一管理和协调，最对资源效能最大化的手段。部门有企业级别的实践方针和指南，结合企业的目标定制了一套最适合本身的组织与技术管理办法，这些规章制度并不是一成不变，是站在企业的角度跟随市场不断去完善和修正的。因此，组织并不是一成不变，既然技术与架构是相互的，那么技术架构的稳健、灵活、易扩展等特性应该一样要应用于组织架构。

 

● 研发小组

　　研发小组跟PaaS同样，是技术组织效能的“加速器”，增长了上层的业务或应用的灵活性和增长快速适应市场的能力。咱们研发小组的贡献主要集中在两个层面。一方面是不断完善和提升本身组织的内部效能，主要体如今咱们当前自主研发的“统一工做台”，这个统一工做台主要是结合咱们各类职能流程和软件工具（如SVN，Docker等）打造的一个统一规范工做流平台。另外一方面是不断经过业务驱动积累咱们研发的业务产品（如咱们“微服务应用中台”的服务沉淀），为企业增效，提升市场竞争力。

 

● 职能小组

　　咱们部门的人员架构是一个“矩阵型”架构，横向为技术职能小组，纵向为以项目经理带领的项目小组（下面会介绍）。按职能维度，整个部门划分为项目经理组、需求组、UIUE组、前端组、后端组，测试组、实施维护组等职能小组。有点相似于微服务架构里面的服务同样，分工合做，独立部署独立运行。职能小组内部会根据规模而进一步细分小小组。这些小小组会随企业发展而又有可能归类为事业线小小组或业务领域小小组。组员到组长一层层向上按本身领域范围的技术规范和项目质量负责。

 

● 项目小组

　　项目小组是咱们“矩阵型”架构的纵向划分维度，由各职能小组成员组成，由项目经理以业务为统筹和主导。在纵向维度，职能会存在一个“项目职能负责人”，确保本身的职能价值在项目中最大化体现。哪怕项目再小，职能只需分配一我的或半我的，而那我的就默认充当了这个“项目职能负责人”的角色。就像微服务架构同样，有了咱们“微服务应用中台”的支撑，顶层的应用场景能够更加灵活、高效、快速地实现。咱们的项目小组在职能小组明确分工的基础上，一样也能灵活、高效、快速组件出打造顶层应用场景的项目团队。

 

　　看到这里，可能有人会有疑问，咱们只是一个小企业，那有这么多人。其实问这个问题的人，等同于问“微服务是否只能适用于大型系统”的问题同样。我在《小型系统如何“微服务”开发》中也作过介绍，微服务是一种方法，适用于任何应用和项目，跟项目规模没有关系，哪怕我目前只有一台物理服务器，或者我只有一个技术人员，都彻底能按照咱们以上的“技术与组织结构”方式去运行和操做。要明确一点的是：方法跟规模没有关系。当今在技术圈比较流行的一个词叫作“DEVOPS”，其实就是一种“降本”手段。咱们的组织架构是跟人数没有关系的，更可能是咱们的管理办法，由于作事情须要顶层方法去引导咱们更好地执行。就算咱们技术组织只有我一我的，也不妨碍我属于研发人员，同时又兼容前端、后端、测试、实施、维护的职能，以及做为项目经理主导本身去开发项目。

 

　　方法还只是属于“虚幻”层面的东西，具体仍是要考本身的实践去验证和发展，就算我说得多牛X，若是不亲自去体会、感觉和总结，咱们持续实践了千万级用户数应用平台近10年的时间，以及咱们所开发的应用系统足足比别人下降数倍乃至数十倍的时间和金钱成本，都不关大家的事，这是咱们每一个同事经过汗水和努力所换来的成效。但咱们的不足还不少，没事，时间还很漫长，一步步主动去学习、改变和完善就是了。