大白话一个系统可以以微服务架构进行规划和设计的前提条件 —— "基础设施由研发之外的团队来维护"。
1. 前言
对于一直在传统软件行业进行职业生涯的"敲代码的"，虽然一直有阅读和思考，并且关注微服务的相关理论和技术栈实现，但在实际的项目落地过程中却对其抱着敬而远之的态度。
过往我也陆陆续续总结过自己对于微服务的一些浅显看法（详见底部链接），但最近在实现skywalking扩展实现——监控数据的动态上报时，因为这个需求与笔者过往反思以及对于软件研发的理解存在路线式的根本差异，所以关于"到底什么样的场景下才是确实需要微服务"的问题再次横在了笔者面前。
这个问题在上一次总结之后，经过多年的沉淀，不出意外又有了一些表述更为清楚的思考，其中的部分正如在skywalking扩展实现——监控数据的动态上报里提到的：
“除非系统体量达到必须微服务，否则业务方绝对不会愿意在基础设施和运维上投入成本，只希望越少越好。即使是他将微服务的要求写在了招标文件里。你有一千条，一万条理由痛诉对方多么不专业，多么坑爹；但回到现实你依然还得直面这个问题。”
业务体量不是必须得微服务，那么用户势必不愿意在日常运维上投入太多的成本；但微服务架构经过多年的争论，终于用残酷的现实教育了所有将它当作马良神笔的从业者——别以为复杂度消失了。微服务只是将复杂度转移到基础设施上。CI/CD你没有，遭罪的是你自己，打碎牙你能自己咽；但链路追踪你要是没有，客户报告问题一般都是火急火燎赶deadline的时候，你猜他会不会和颜悦色跟你哥这演练"和人交流要讲礼貌"。
2. 大白话之"何时开始微服务化"
前言部分更多的从面向现实的角度来解释我们必须要考虑面对微服务的代价，而不是只考虑到其好处就贸然做决定。但对于初次接触微服务，或者更直白点没有挨过微服务打的同学们来说，再进一步的指导标准和执行准绳是很有必要的。
在这一点上其实前辈们已经从各类不同的角度给出过各种参考线，诸如：
- 当规模大到了『每一次部署都是全部部署』这事让你们感觉到『痛』的时候。
- 要达到什么样的规模才适合分布式/微服务架构?
我这里给一个更为贴合传统软件行业的，现实性的标准：
相关的基础设施是否由专门的团队，至少是非研发之外的团队来负责？
这里的基础设施指代的是consul / nacos这样的注册和配置中心，监控的服务端，redis缓存集群，mq消息集群等等。
如果这个答案是肯定的，那么说明相关方都对于践行微服务的利弊有着较为清晰的认识，那么这个软件产品的微服务之路会比较顺畅；但如果这个答案是否，那么：
- 如果你是一线小兵，那就多攒点面试经验，正好这个项目可以让你练习各种高大上的微服务技能。
- 如果你是关键角色，那也得恭喜你；所谓"不经历风雨怎能见彩虹"，所谓"人教人，一千遍不会；事教人，一遍就会"，相信初次了解微服务的人都会被其宣称的愿景所折服，迫不及待想试试，作为负责人的你在撞到南墙前一定也是这样想的，所以宜早不宜晚，你能早点醒悟不论对于你个人，还是公司都是有着相当裨益的。
3. 一些个人建议
系统微服务化有两种方式：
- 旧有系统的改造，焕发第二春。
- 新系统在构建时的设计。
如果属于情况一，团队一般不会过于激进，而且会有大牛在左右护航，这种的改造不说四平八稳，但成功率都还是有着相当保证的，这也是系统微服务化的推荐思路。
但是如果属于情况二，那么我有如下几点个人看法：
- 这种情况一般而言都是甲方的合同要求，加上团队成员的各类小心思，这个时候负责人一定不要迷糊，控制住步伐，千万别扯到蛋。
- 至于你说"甲方合同都要求了，我还能怎么办？"，那么请记住这句话："只要有目标，就一定能达成"。注意这里要强调的是，我并不是想要教坏你。微服务不是你的目标，以可接受的成本让甲方满意才是。
- 最后，如果你做的是一个长期维护的产品，而非一锤子买卖的项目，那么我建议你在设计之处就要考虑传统版本和微服务版本并存的情况。这会让你在设计时多方掣肘，但两者都是为了面对现实，而无论如何最终你一定需要面对现实。
网友评论