又让马儿跑又不让吃草，微服务化如何完成低成本改造？

小编一哥们和我吐槽自家的烦恼
本来一个有钱有闲的证券行业IT经理
一年前被老板派去支持创新业务探索
由于新型业务在不断加速铺开
当前的单体式应用复杂度愈来愈高
业务上线过程繁琐、流程冗长
资源分配耗时较多
更新频率愈来愈低
人员也愈来愈显得捉襟见肘

这哥们因而开始了加班第1、女票第二的人生
把本身都当成牲口使唤
仍是免不了遭到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应用
这就实现了真正的低成本
固然
肯定微服务技术平台打造三类工具以后
在微服务化过程当中还有不少的细节问题
好比服务调用失败的处理
企业须要不断学习业界先进的方法
这方面社区有不少最佳实践能够参考

小结

实施微服务是为了提升效率下降成本
一切不能降本增效的微服务都是耍流氓
开源开放是当前业界的主流选择
但基于开源、门槛低、无侵入、功能完善的平台
才能让企业真正实现低成本的微服务化
快速解决业务痛点
经过技术红利促进企业的发展
这也是 网易云轻舟微服务平台的设计理念

相关文章：
【推荐】 std::shared_ptr之deleter的巧妙应用
【推荐】 dubbo异步调用原理 （1）
【推荐】 react技术栈实践（2）