微服务重构四步法

本文是【技术琐话公益直播】5月27日晚分享嘉宾潘志伟在线直播中主题《微服务硬核实战》内容整理，内容有删减调整，直播回放见之前的分享。

1 —

如何正确开启微服务

一般情况技术人员需要思考项目使用服务的流程为，框架的选型（spring cloud、dubbo、自研等），跑通微服务项目的案例demo，在以为掌握的情况下开始做计划，并开始做项目。以下通过案例分析几个失败的案例。

案例介绍一：改革需要试错的成本

现象:某公司打算转型微服务架构，招聘了一个有微服务经验的架构师，经过2个月高频率开发后第一个服务化的模块上线了，但是上线后出现了生产事故，最终以技术不合格为由开除了架构师。

分析:对结果负责的思想可以理解，但是过程也非常重要。在做微服务架构初期的时候，公司管理层要容忍研发适当的错误。

嘉宾观点：改革需要试错成本。

案例介绍二：项目架构调整要获得老板的认可

现象: 有个架构同学反馈，他在公司推行微服务太难了，根本推不动，硬件资源没有， 人力资源也没有，全部都是自己一个人一个模块一个模块的改造。

分析:主要原因组织上没有认可，所以没有任何资源，这个项目注定是一个失败的项目。

嘉宾观点：技术架构的调整不能仅凭技术的满腔热血，首先要获得老板的认可。

案例介绍三：时间紧急，导致项目失败

业务极速膨胀，公司的CTO也是搞技术的，也认可搞微服务，人力资源部门全力配合招聘研发人员。前提条件是不能影响正常业务迭代，而且微服务整体时间范围要尽可能的短。

结果:因为时间紧，每个小团队快速启动开发，结果工程结构各式各样，部署脚本很难统-，结果失败了。

嘉宾观点：

磨刀不误砍柴工，前期充分培训非常重要。

整理一套适合团队的标准代码结构同样重要。

从上面三个案例，我们知道一个微服务的的开启，需要项目负责人、公司承担需要试错的成本、需要获得老板的认可、需要足够的时间去尝试，缺一不可。那如何落地微服务重构了，这里我们介绍微服务重构的四部法则。

2 —

微服务重构四步法

 

3 —

微服务实战技巧

服务到底怎么拆分？微服务拆分多少合适？这个在市场上面很少有看到类似的书籍来告诉的我们的系统应该怎么拆分。因为每家公司的业务和场景、形态都不尽相同。这里我们根据三个维度进行拆分。

1.初级阶段以功能为力度拆分

2.以迭代频率拆分

3.以接口粒度拆分

关键技术：分布式Session

4 —

总结

1、微服务并不可怕，怕的是你没搞定领导

2、优化无止境，好的设计减少后续优化成本，有时候提高硬件设备是最优的优化

3、架构本着可用原则，不要过渡架构。架构low点不可耻，可耻的是项目延期、上线后线上Bug频发

4、不要企图规划3年后的架构模式，有可能不到3年你就把自己的架构推翻了

- END-

参与相关讨论，请在公众号回复关键词：读者群。

参与相关讨论，请在公众号回复关键词：读者群。 

阅读推荐：

从业务架构视角聊聊大型商业银行的转型实践        

从平台到中台【上】

从平台到中台【下】

关注成效而非产出，不要战术繁忙

蚂蚁金服语雀产品技术负责人：用 JavaScript 全栈打造商业级应用

技术琐话 

以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。本号由坐馆老司机技术团队维护。