我们真的需要微服务吗？

最近看了两篇微服务文章，结合之前的一篇微服务笔记，对近期的微服务相关内容及思考做一个总结

文章概要

这篇文章的作者开始调研了微服务，最后放弃了微服务

这篇文章总结下来主要有一下因素影响迁移到微服务：

1. 架构严重依赖第三方
2. 架构边界不清晰，无法有效拆分微服务
3. 不同团队共享服务代码
4. 基础设施不够完善，如果要
5. 团队经验不足，对未来规划也不清晰+时间紧张

此团队对微服务进行反思，分析微服务到底有哪些好处：

1. 团队自治程度更高
2. 开发团队可以专注特定领域
3. 良好的伸缩性
4. 更容易回滚
5. 易于重构,更高的发布频率,升级更简单
6. 使用最合适的技术
7. 缩小变更影响范围

作者发现这些好处并不能给当前团队带来帮助 ，作者认为，微服务同样有代价，需要解决很多问题，例如：基础设施，架构的复杂化，api，开发环境的膨胀等。
作者最后提出观点：微服务更多与技术无关，认为更多与团队的结构和工作模式有关，而不是纯粹的技术问题，作者最后又提出了更多问题，主要是微服务边界和职责划分的粒度问题。

笔者小评：感觉这个作者主要是因为经验不足和业务架构划分不太合理，和国内公司有点像，准备不够充分

第二篇文章 记录了一次对Davide Taibi博士的访谈,这里对一些重要问题进行总结：

1. 从单体到微服务转型需要较长周期（数年），它的优势在于团队的独立性，而不是简单的降低成本，在很多实例中，转型都没有得到期待中的回报。
2. 微服务的最坏反模式在于组织而不是技术，技术上的反模式容易纠正，而组织的则很难纠正。
   两个反例：
   • 团队按照水平划分而不是业务领域垂直划分
   • 微服务贪心：开发者对于任何功能都创建微服务，而不去考虑复用，导致微服务数量暴增，结构迅速退化，维护的复杂度和成本也激增
3. 单体架构面向的系统相对较小，微服务一般用于开发团队较大的情况
4. 博士相信未来AI将会影响架构分析领域到一个很重要的程度，而不仅仅是GPT类

个人思考

从上问可以得出几个观点：

1. 微服务关于组织，而不仅仅关于技术

2. 微服务的好处

   1. 更小而精的团队
   2. 业务领域划分更清晰，开发团队可以更专注特定领域
   3. 良好的伸缩性、更小的变更影响范围、更易于重构
   4. 更容易迭代、升级、回滚
   5. 使用最合适的技术，对业务有帮助

3. 微服务的坏处(或者说需要考虑的点)

   1. 微服务增加了架构层面的复杂度
   2. 微服务需要组织架构变革
   3. 微服务需要更强的基础设施
   4. 微服务实现对数据一致性的支持比单体服务要更复杂

4. 在实施微服务前要明确你的业务目标，思考微服务的好处是否能达成目标，不能为了技术而技术

TODO

哪些是适用微服务的场景，哪些是不适用的，需要再思考