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

背景

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

为何要作微服务

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

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

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

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

带来的问题

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

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

总结

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

最后，给出两点建议：

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