【微服务】开启巨石应用到微服务的探索

2019独角兽企业重金招聘Python工程师标准>>>

背景

在过去的一年时间里，我一直在从事一件事情，将现有的单体应用（巨石应用）向微服务改造。 接下来，将持续整理一些在微服务路上的学习与成长。

为什么要做微服务

单体应用，开发、部署简单，适合于小项目快速开发。但随着业务增长，也会暴露出一些问题：

1. 代码错综复杂。代码相互依赖，经常出现修改一个bug，却影响了其他功能模块。
2. 资源抢占，相互影响。整个系统运行在一个进程中，时常因为导出大量数据导致服务响应时间过长，严重影响用户体验。
3. 性能优化困难，不便扩展。有的服务是IO密集型，有的服务是CPU密集型，在同一个项目的时候，只能购买更高配置的机器，成本过高。
4. 系统升级效率慢。新功能开发和bug修复周期时间长，修改后，回归测试执行较长。
5. 学习成本高。业务越来越多，新加入的同事不能快速上手。文件数量多，业务耦合度高。

而引入微服务后，将各个模块按照业务单元拆分后，将较好的避免以上问题。

1. 微服务本身可以按照自己的计划进行维护升级，只需要保证接口和参数格式稳定，将不影响其他调用方。
2. 对于qps较高的服务，可以通过扩展节点数量，提高服务吞吐量。
3. 程序运行独立的环境中，避免资源抢占。

带来的问题

当我们享受微服务带来的幸福时候，也要明白这样架构，所带来的复杂性。

1. 自动化运维（DevOps）。服务数量越来越多，系统配置，运行情况，上线操作将指数型增长。如果还依旧像单体应用的时候，人为处理，将变得非常吃力。
2. 服务调用时候，超时机制。服务在网络中调用时候，如果遇到超时后，如何重试，如何避免数据重复提交等问题。
3. 分布式事务。在单体应用中，我们可以通过spring的事务管理器很容易实现。但微服务后，如果使用跨数据库的分布式事务，将严重影响性能。如何根据业务解决数据异常带来问题？

总结

微服务探索中，痛并快乐着。

最后，给出两点建议：

1. 微服务不建议一下拆分很细，增加系统维护成本。最后粗略拆分，不断迭代，拆分。
2. 微服务拥有独立的数据库，不可共享。数据访问必须通过服务调用实现。虽然很痛苦，但是坚持下来很不错。

转载于:https://my.oschina.net/u/161336/blog/1931687