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

小编一哥们和我吐槽自家的烦恼
原本一个有钱有闲的证券行业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应用
这就实现了真正的低成本
当然
确定微服务技术平台打造三类工具之后
在微服务化过程中还有很多的细节问题
比如服务调用失败的处理
企业需要不断学习业界先进的方法
这方面社区有很多最佳实践可以参考