引入微服务时的至少6个问题考虑

1、引入的复杂性

微服务在使用中会带来各种各样的成本的提升,也会引入各种各样的技术问题。最终就会导致系统整体复杂性进一步提高。当复杂性提高的时候,为了保证系统的稳定,就需要整体技术团队的靠谱,就需要技术人员的靠谱,就需要整体技术设施搭建的靠谱。在引入微服务之前,扪心自问下,这些贵司有吗?有这些团队、这些设施、这些资源吗?

2、分布式本身带来的成本

分布式需要一整套完整的技术体系和设施去支撑整体分布式的建设。例,以前单体项目只需要一个项目,直接人工上线就好了。现在呢,可能会出现几十个上百个项目,这些项目如果全靠人工去做,会彻底让团队人员疯掉。所以,就需要把整体发布,部署自动化起来。这里还仅仅是发布部署所需要的,还没有谈维护问题。

3、维护和监控服务所需要的 DevOps 团队

微服务需要维护和监控,确保运行的稳定和可靠性。在微服务的实践里,是非常推荐搞DevOps 的。DevOps 需要的工作人员的工作态度和责任心问题及对人员水平的高要求。整体运维的平均水准加上开发水平的要求,这个团队搭建下来要花的资源?贵司舍得投入吗?

4、微服务所需要的经验

微服务是很复杂的,从计划分模块开始,就需要架构师必须对架构设计和微服务本身对应的 DDD 领域驱动设计非常有经验,能够恰到好处的划分出对应的模块。否则,一旦设计完毕,不甚把一些紧耦合的服务给硬是解耦成了不同的服务,那么,这个后果对整个技术团队甚至对整个项目团队都是灾难性的。同时,对于微服务的开发、维护、运行、保障以及运维,都需要技术团队成员要有很丰富的从业经验能迅速发现,定位,解决可能随时出现的问题才可以。如果技术问题不能及时解决,那整体系统的体验就可想而知了。

5、链路测试的方法

为了快速追踪定位死锁或者共享资源的问题,微服务需要靠谱的调用链实现。那么,这就引出的新的问题:我们如何搞全链路测试?我们是不是还得搞一套合适的全链路测试工具才可以?这全链路测试工具开发又需要花多长时间,需要投入多少人力?测试人员的水平是不是也需要得到一定的保证?

6、微服务日志

微服务本身有多个节点,这些节点为了自己的安全运行和维护,需要很多自己独有的日志。这些日志随着微服务的增多,也越来越多,如何存?如何查?如何删?这些都要考虑在内。

最后

并不是什么新技术,热概念都适合自己的团队、自己的项目的。做一个合格的架构师、技术负责人,首先应该遵循的是 KISS 和 YAGNI 原则。

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注