你真的需要微服务吗？

2020-07-02 00:00:00 微服 架构 技术 企业 服务



1概述

随着云、基础设施自动化、虚拟化、容器化的发展，布道多年的持续交付，在国内企业开始落地，许多组织尝试使用更细粒度的服务架构来实现可更快的交付，结果发现其带来了更好的扩展性、更易敏捷开发、增强了团队自制。随着互联网巨头逐步开源微服务架构并取得了不错的反响，微服务受到了前所未有的关注。但究竟什么是微服务架构？我们真的需求微服吗？本文基于同CTO、架构师朋友交流，并结合笔者多年互联网金融服务化实践及思考和大家聊聊微服那些事。


2我们真正需要什么？


2.1 创业CTO观点

当下google、AWS、Netflix和国内BAT等企业引领SIMM（Service Integration Maturity Model）发展，而大量的传统和初创企业还处在初级阶段向服务化演进阶段（如下图所示）。



(摘自：《面向服务的企业应用架构》)

技术为业务而生，如何更好地来服务于业务，面对众多的技术选择，如何甄别出适合自己公司业务的技术成为CTO需要考虑的问题。

CTO首先要把握好企业技术发展的“愿景——目标——路线”：

  • 愿景：就是给大家指明方向，作出技术选择，并考虑他的短期和长期影响；
  • 目标：制定阶段目标以实现愿景，这也是战略的核心；
  • 路线：就是实现目标需要做的事和步骤，这个是战术层面的。

从企业长远看，微服务只能算是战术，是需要为战略服务的。

当企业处于初创阶段，CTO要控制技术风险，以验证业务模式为主，是否采用微服务架构需要考虑以下几个主要因素：

  • 技术方向选择分布式、还是集中式（好而知其恶，恶而知其美——理性分析优劣后制定符合业务模式的架构）；
  • 根据战略方向，界定好技术栈边界，不做越界的事情；
  • 仰望天空，脚踏实地，根据团队人员技能、人员规模、IT预算等制定符合当前实际情况的路线；

在进行：语言、技术、库、框架等技术选型时，创业初期建议捡团队熟悉的、高效的用就行了。后期为了提升产品性能和体验再考虑优化的事。技术只是服务于产品，整个团队的重心如果都放在技术细节上，尤其对于创业公司，一开始就过度构建他们的项目。每个人都认为，他们的公司会成为下一个 ‘独角兽’（如Netflix一样），因此，他们使用微服务构建任何一个东西，或者一些其它的高扩展性的基础设施。但是这通常是一种错误的做法，在这种情况下，后的结果很可能是浪费了时间和努力。

企业进入快速成长阶段，随着业务规模的扩大，团队规模也在扩大，当前阶段大的矛盾是：

  1. 后台支撑系统已经不堪重负，吞吐量、稳定性以及可扩展性上都无法满足日益增长的业务需求；
  2. 生产故障频发，有快速蔓延的趋势，大量人员参与救火已经影响到新需求开发进度，开发效率低，无法满足公司高速发展的需要；
  3. 新员工需要快速入手，如果没有老员工的传帮带，频繁试错式成长成本太高，而老员工救火之余也希望有新的机会成长，无暇顾及培养新人；
  4. 新的商业模式要求开放内部业务能力，需要重构应用和服务。
  5. 技术团队和系统都需要拆分，是横向按照业务横向拆分，还是按照技术进行垂直拆分亦或立体拆分（建立Devops团队）？


为了解决当前面临的问题，大部分技术驱动公司希望微服务能够带来更好的可维护性，并降低成本。但如何避免为了技术而技术的盲从，制定负责企业当前现状的实践路线，成为CTO需要考虑的问题。是避免新瓶装旧酒进行大范围系统重构，还是允许新瓶装旧酒采用Sidecar模式快速享受新技术带来的好处？这个是个问题。根据创业实践经验，总结了一下原则和策略供参考：

  1. 构建基础架构创新小组，进行服务化、服务治理、自动化部署、全栈监控、统一日志收集及问题溯源分析等技术选型。
  2. 制定架构规范原则、切换路线、方案。
  3. 遵循架构演进原则，通过服务化逐步将系统功能进行拆分，分解成多个独立的服务。


随着团队微服务实践的尝试，整个微服务架构体系和敏捷团队已经成功构建出来了。根据带人经验，一个人管理5-6个人是比较合适，多了会使核心骨干无法专注于具体事务而将过多精力放到沟通和团队管理上，而影响产出和效率。因此，在执行过程中不断总结经验，优化：技术栈、交付流程，并通过组织架构调整驱动微服务架构落地。



2.2 金融机构CTO观点


如果从道与术的角度看，我们要避免追求术而忽略的关键的道，这个道是什么，就是传统金融要转变躺着赚钱的业务模式，模式变了技术愿景就变了，阶段目标和路线也会随之而变。

当下，互联网不仅推动了API经济的崛起，同时也推动了银行、保险等多个行业领域的经济运行模式和产业结构的调整，兴起了“API经济”——借助开放API技术，将企业的某些能力作为API服务而进行商业交换的经济模式。API经济有几个特点：

一是标准化，能够让银行机构对外提供标准的核心服务；

二是自助性，简化了其它企业与金融机构服务的对接流程；

三是多级性，即封装好的API服务可以再次封装，为金融服务融入到不同业态提供了很好的模式。




从目前看微服务架构适合API经济模式，根据Martin Fowler对微服务的定义，微服务的特性可以帮助传统金融企业走向开放的商业模式。从国内金融机构现状看，技术驱动的需求相对容易推广，但微服务的其它特性需要对组织架构做出相应调整，以适应产品、业务能力，而往往组织架构的调整是成功实施微服务的关键因素。当然我们也看到一些变化，为了提升金融科技驱动金融服务的创新，国内的建行、民生等银行纷纷成立金融科技子公司，以其解决受限于银行体制机制问题，银行难以像新型金融科技公司等在技术上大幅投入，对科技人才给予充足的激励机制等问题。

与SOA方法论不同，微服务架构是一种架构风格，它把一系列协作的服务组织成一个系统来支撑业务。微服务可以提升自主开发能力，但需要全栈监控与运维能力，才能确保系统稳定运行，因此引入微服务需要评估其实施的投入产出比。

如果我们将企业商业上的成功与所做的事总结一个公式：

企业商业上的成功 =战略关键事务*成功率*做事的速度

那么，微服务架构可以快速完成重要业务验证，因为采用专人、专业的工具/开发语言、做专业的事，所以提升了成功率和做事的速度，从这个方面来讲微服务可以在技术架构层面支持企业创新和成功。


越来越多的实践证明，企业为了在市场竞争中确立领先的位置，必须快速成长，拥抱混乱无序的状态。而微服务的架构的应用，对于快速扩张是完美的解决方案，这并不是完全出于技术的原因，更多是技术团队快速增长、功能快速上线带来的压力。当公司快速增加大量工程师，以很高的频率上线新功能的时候，要让开发人员快速进入角色，微服务架构大概是可行的方式。微服务归根结底是用API通信代替人的交流，人类的交流中会出现信息不对称，会涉及团队政治，与此相比写代码要简单高效得多。



2.3 架构师观点

我个人觉得如果只求实现微服的框架如spring cloud等则只看到了微服务架构体系的冰山的一角，你看到的美好下有一个巨大的坑需要填。





这冰山下隐藏了一些互联网应用在设计过程中需要遵循的一些基本原则（12-Factor，如下图所示），这些原则在微服务实践过程中同样要遵守。





微服务的本质是一种方法，它开发一个单一的应用程序来作为构成整体服务的小服务，每个小服务都运行在它自己的进程中，并且使用一个轻量级的机制进行通讯。这些服务都围绕业务能力来构建，并且可依赖全自动部署机制来独立部署。这在一定程度上解决了伸缩性问题、运行效率问题、开发效率问题，并支持在纵向和横向两个维度进行伸缩，促进新旧技术和架构的更替。

根据以往服务化经验，在推进微服务过程中，建议做到以下6点：

  1. 乱中有序——寻求共性，实现服务的标准化；
  2. 序中有乱——架构设计时支持变化，类似集装箱追求内部创新；
  3. 从设计到交付，每个环节都要确保服务的高可用；
  4. 支持商业模式和产品的创新（加法）、架构设计力求做减法，以让开发团队从简单中掌握复杂，实践创意、作出产品创新；


  1. 构建微服务生态，以稳定可靠、可伸缩、可容错的方式来构建、维护和标准化微服务相关设施。根据业界实践，微服务生态可以分为四层（如下图所示），底下三层基础设施层，从中可以看出，稳定、可伸缩的基础设施平台是构建和运行微服的保障；


  1. 微服务项目是以业务为驱动的端到端交付过程，从架构角度我们重点关注：服务规约、架构设计、服务实现三个方面，但从面向企业交付价值的角度需要关注以下9方面相关内容：



Netflix团队作为微服务的先驱，提出了5条设计和实现微服务架构的佳实践，供读者在推动微服务过程中借鉴：

  1. 每个微服务的数据单独存储
  2. 使用类似程度的成熟度来维护代码
  3. 每个微服务都单独进行编译构建
  4. 部署到容器之中
  5. 将服务器看做是无状态的


3放眼未来


从Gartner对微服务技术解读我们看到，从开发人员的角度来看技术依赖趋势，当前正处于微服务阶段，如果按照10年一个周期来看，那么接下来会是什么?Service Mesh还是云原生，还是区块链，这个留给是时间来检验。





从Gartner中国新兴技术成熟度曲线，看数字金融、大数据、PaaS、SaaS和IaaS目前国内尚处于技术发展阶段，在技术采用和服务成熟度等方面距离国际先进水平还有距离，作为金融IT从业者的我们在接下来几年可能会看更多到相关技术在金融业落地。



技术变化如此之快，我们如何在技术更迭如此快速的技术潮流中立足？我个人的建议是：注重自身的提高，训练计算机思维和工程思维；熟悉底层技术架构和原理，以谦逊和开阔的心胸迎接挑战。从过去几十年软件发展趋势看，运行良好的系统都是不断变革的产物，当前的系统纯粹是适应时代和技术发展演变而成的——这个是变异和自然选择的结果。

根据达尔文的“适变理论”与性选择理论：达尔文用它来解释第二性征的演化缘由，比如达尔文无法理解雄孔雀为什么长出一个明显和生存无关乃至危害生存的尾巴？他后来发现，问题可能出在母孔雀身上，那些没长大尾巴的孔雀都绝种了，因为没有雌孔雀愿意与它们交配…… 同理，在现在和以后几年，技术人员在面试时经常会被问到是否熟悉微服务，很多企业在采购选型时明确要求采用某某技术架构，要求技术架构的先进性，这些很可能成为常态。



4总结


本文从创业CTO、传统金融机构CTO的角度讲了不同企业在不同阶段技术选型的策略，参考了Netflix和Uber等企业在微服务架构设计经验总结，结合笔者多年推动服务化建设经验，从架构师的角度讲了微服务落地需要考虑的原则和需要关注的内容。

参考文献：

《面向服务的企业应用架构》——颐春红、于万钦著

《微服务设计》——Sam Newman 著


本文为《大话分布式》系列文章的第七篇，后面还会分享互联网金融服务化经验和微服务架构相关内容。前六篇为：

  • 百亿级金融应用分布式缓存实践
  • 大话分布式架构(五）- 熔断隔离
  • 大话分布式架构(四）-MQ
  • 大话分布式架构(三）——RPC框架
  • 大话分布式架构(二）——API网关
  • 大话分布式架构(一）——简介


关于今天我们讨论的观点是否对你有帮助呢？你的朋友是不是也在准备开始微服务之旅呢？你把本文分享给好友，看看他如何看待微服务架构的。


weixin.qq.com/r/Jy99ZRj (二维码自动识别)

相关文章