为什么大部分码农做不了架构师？成为架构师，不仅仅是工作上的简单积累，更需要主动接纳工作外的大量知识。

本文是服务治理领域的一篇文章，着重从一些更贴近我们实际工作的角度来进行更抽象层次的剖析，分享一些我认为重要或者有意思的方法论和逻辑推演过程。希望能给想成为架构师的码农们，在无论是业务应用还是基础技术领域的服务治理提供一些参考。

01

我们到底需要什么样的微服务？

开篇之前，想问大家一个问题，我们需要什么样的服务治理？

这个问题很好回答，同时也很难回答。简单来说，这取决于三要素的发展现状。取决于你的组织、业务和系统的健康度、匹配度和成熟度。但这个形而上的“道”，如何转换成形而下的“器”，确是需要结合实际场景 case by case 去思考的，没有标准答案。

02

面向应用领域的指导原则

四个问题

网上有很多关于应该怎么拆分服务的文章，更多偏向技术层面。此处不加以赘述，我们讨论四个问题，也是经常困扰我们的四个重要问题：

1. 应该在什么阶段进行拆分？永远不要过早地进行拆分。考虑下你的业务迭代速度是否会引起系统所有权和使用权的竞争，进一步反向制约迭代的效率；考虑下是不是大应用导致你技术升级优化和资源的使用上困难重重；考虑下公司的运维水平和团队成员的素质是不是能够支撑起更细粒度的微服务体系结构。你考虑清楚了这三点，你就知道你是否应该进行拆分了。

2. 应该按照什么维度来拆？大原则上来说，按照业务领域进行拆分即可。在领域之内，进行分层拆解，将接入层、逻辑层和数据层复杂到一定程度的时候进行横向拆解。

3. 服务拆分到多小算小？有一个说法是“确保两个星期之内能够重构”。我比较认同的一个说法—“足够小就行”。没有唯一的衡量标准，这个取决于你的业务发展速度，业务复杂度，技术栈异构程度。很多人的倾向是，更愿意对一些功能在不明确后续发展的时候，尽量能不拆就不拆。这同样也是我的建议。另外建议，确保一个服务只有一个团队在维护，这能避免大量的问题。当你发现有多个团队在维护的时候，说明你可能需要拆分了。

4. 微服务团队需要多大？小团队更容易具备战斗力和凝聚力，也能拥有更好的效率和对未来的应变能力。

03

面向技术领域的指导原则

面向技术领域，这个问题比处理上面的问题要更直接而明确，重要的是其中四个方向：

1. 可运营

2. 高可用

3. 高性能

4. 自动化与标准化

通过本场 Chat，我想分享给大家的一个观点是，不仅要结合实际生产实践来分析具体的系统架构，也可以通过对架构的剖析能进一步地去洞察设计者的意图和思考逻辑，知其然而知其所以然，这是我认为架构师领域非常重要的一个技能！

感兴趣的朋友可以扫码阅读完整原文

也可以来读者圈里给我提问~

▼

点击阅读原文，掌握架构师的必备技能！！