共计 2642 个字符，预计需要花费 7 分钟才能阅读完成。
小编一哥们和我吐槽自家的烦恼原本一个有钱有闲的证券行业 IT 经理一年前被老板派去支持创新业务探索因为新型业务在不断加速铺开当前的单体式应用复杂度越来越高业务上线过程繁琐、流程冗长资源分配耗时较多更新频率越来越低人员也越来越显得捉襟见肘
这哥们于是开始了加班第一、女票第二的人生把自己都当成牲口使唤还是免不了遭到 Boss 痛批：业务需求响应速度像乌龟一样一个小问题也会影响整个大项目严重拖了公司业务创新的后腿
Boss 参考同行后给他布置了一项新任务——在低成本、不影响业务的前提下试水微服务化
抱怨 Boss 既让马儿跑又不让马儿吃草的同时哥们第一时间就想到了主流开源方案于是成天啃 Spring Clouod 甚至到了不问女票的程度小编不能眼看哥们在注孤生的道路上越走越远决心挽救他身后站着网易云轻舟微服务的众多大神就是这么自信其实这也不是个别问题当微服务成为数字化转型升级的钥匙很多企业都想微服务化以争取（或是保持）行业领先地位如何实现前沿技术与企业业务的融合就成了每一位微服务项目负责人的烦恼解决这个难题当然要从企业的困惑说起
企业微服务化的困惑企业对于微服务化较为普遍的困惑 第一是 微服务技术复杂 且不说包括容器化、DevOps、微服务监控的全家桶 单看核心的服务治理 昨天 Dubbo 今天 Spring Cloud 明天 Service Mesh 组件众多且学习曲线陡峭 对于传统企业 IT 团队来说实在强人所难 不知道从何处下手 况且企业承担人力成本是为了业务而非学习 第二是 微服务收益难以预估
微服务技术来自互联网领域 诱惑是规避单体应用的笨拙 通过分而治之来提高市场响应效率 单个服务的开发运维成本大幅降低 甚至新人也可以快速上手项目 但传统企业情况不同 微服务如此复杂的体系 若实施不力设计不合理 整体复杂度的增加是妥妥的 会出现画虎不成反类犬的尴尬 再吸收经验重新调整 所耗费的时间和人力也是难以预估的 第三是 预算有限 IT 预算整体缩减的背景下 收益不确定的项目的预算就更不用说 容易缺乏长远的规划 所以，企业对微服务的要求是 好用 + 易上手 + 低成本 好用是能满足各种功能和非功能性需求 易上手是指不需要团队太多的额外学习 低成本不仅仅指引入平台的采购成本 也包括使用和维护成本 Java 比较 6 的哥们，半个月都搞不定 Spring Cloud 其实就算搞懂了 Spring Cloud 社区版本 项目也是需要重新修改业务代码的 这就是所谓的“侵入式框架”也是高昂的成本
引领微服务化的策略小编和网易云轻舟微服务大神们聊过后 总结了企业实施微服务化的通用策略 首先是 战略层面 如同 10 年前将信息化作为一把手工程 明确应用架构非微服务不可的前提下 企业必须让管理层挂帅推动微服务化
因为微服务作为实现 DevOps、云原生的方法 不仅仅是一个技术问题 牵扯到 IT 架构、应用架构和组织架构 单靠开发团队或者运维团队是无法完成的 需要打通组织、流程 战略目标及相关预算的制定 最好邀请了解行业、精通技术的专家参与 同时 要明确微服务化是一个渐进的过程 不可能一蹴而就 事实上 网易业务也是处在不断拆分和组合中 其次是 战术层面 要牢抓“一个核心、两个关键、三类工具”一个核心是指实现 DevOps 为业务提速 DevOps 是微服务化的核心目标和重要保证 如果不考虑 DevOps 就无法解决哥们遇到的那些问题 微服务化对业务还是没有实际意义 如果没有持续集成 / 持续交付（CI/CD）、自动化测试 如果开发团队不承担环境配置之类的运维工作 微服务化就会因为引入复杂性而失败 围绕这个核心 需要明确微服务架构设计工作的全貌 有了全局的观念 才能正确规划微服务化的步骤 根据网易云首席架构师刘超的分享 微服务的实施需要解决如下 12 个具体问题 两个关键之一：业务拆分 高内聚低耦合的拆分原则 本质是单一职责和职责分离 首先必须定义好服务边界 全新设计的系统的重点 是业务边界确定和服务间的通信方式 对于边界不直观的业务 宜合不宜拆，宜缓不宜急 而现有系统的服务化改造 要重点关注系统架构的平滑过渡 也就是实现“开着飞机换引擎”平滑过渡需要逐步改造 两个关键之二：服务治理 大量小服务有序、稳定地合作 背后必须有过硬的服务治理能力 要认清微服务化的 3 个阶段：以服务注册 / 发现为标志的 1.0 阶段 以熔断 / 限流 / 降级为标志的 2.0 阶段 以 Service Mesh（服务网格）为标志的 3.0 阶段 目前有意实施微服务的传统企业 基本都是在向 1.0 阶段过渡 传统行业领头羊则在向 2.0 阶段过渡 企业一般需要循序渐进 比如说 Spring Cloud 只支持 Java 编程语言 Service Mesh 支持多语言且对业务侵入性最小 直接上 Service Mesh 不是更好吗？其实 Service Mesh 主流平台 Istio 的设计 是弥补 Kubernetes 容器平台的微服务管理短板 如果业务没有完成容器化就上 Service Mesh 运维会工作那是相当的麻烦 当然 1.0 之前也建议尽量先无状态化、容器化 这样可以减少运维和持续集成的很多工作 所以 网易云轻舟微服务平台的设计 治理框架同时支持 Dubbo、Spring Cloud 和 Service Mesh 基础设施同时支持容器、虚拟机和裸机平台 大神们认为这是“好用”的基础之一 三类工具包括治理 & 监控、容器云和 DevOps 一个好用的微服务工具平台 应当满足微服务的核心和关键需求 最终要能够一站式 hold 住 12 个要点 随着微服务的拆分 只有 服务治理还不够 需要 全链路监控协助发现瓶颈、定位故障 其未来是 AIOps（智能化运维）DevOps 不仅需要 CI/CD、自动化测试 也需要 容器云平台的支撑 易用的微服务平台 应当是背靠专业服务的成熟产品 通过单一图形化解决完成应用的管控 尽量消除微服务带来的复杂性 让企业能够专注于业务 低成本的微服务平台 应当实现微服务治理框架和用户业务的松耦合 比如网易云轻舟微服务平台 针对 2.0 阶段的服务治理框架 基于 Spring Cloud 打造 通过 Java Agent 动态字节码增强黑科技 实现了代码无侵入式的部署升级方案 也就是说 无需二次修改就能把老应用改造成新的微服务 并且兼容 Dubbo 应用 这就实现了真正的低成本 当然 确定微服务技术平台打造三类工具之后 在微服务化过程中还有很多的细节问题 比如服务调用失败的处理 企业需要不断学习业界先进的方法 这方面社区有很多最佳实践可以参考
小结实施微服务是为了提高效率降低成本 一切不能降本增效的微服务都是耍流氓 开源开放是当前业界的主流选择 但基于开源、门槛低、无侵入、功能完善的平台 才能让企业真正实现低成本的微服务化 快速解决业务痛点 通过技术红利促进企业的发展 这也是 网易云轻舟微服务平台的设计理念
文章来源：网易云社区
