小型技术公司适合做微服务吗？
笔者目前就职于国内知名互联网公司，做过toG和toB的私有化项目的微服务架构设计，也做过大型产品层面的微服务架构设计，就小型技术公司是否适合做微服务这个问题，来谈一谈我的看法。
鉴于问题中已经提到一个已经四年的项目，越来越“臃肿”，那笔者初步可以判定，贵公司已经面临“单体地狱”的困扰了。
首先声明一点：微服务不是解决所有问题的银弹。
微服务的本质，是服务的分解和定义，而不是技术。
如果小型技术公司所做项目的技术架构已经面临“单体地狱”，即单体结构复杂、开发速度缓慢、难以扩展、需要长期依赖某个可能已经过时的技术栈而无法快速升级的情况下，就可以考虑进行微服务化改造了。
这与公司的大小无关，与业务发展速度有关。
什么是微服务架构微服务架构，可以定义为把应用程序功能性分解为一组服务的架构风格。
与规模无关，重要的是，每一个服务都是由一组专注的、内聚的功能职责组成。
微服务架构的好处微服务架构有以下好处：使大型的复杂应用程序可以持续交付和持续部署。
（就算是小型技术公司，也需要小步快跑，紧跟业务的发展）每个服务都相对较小并容易维护。
服务可以独立部署。
服务可以独立扩展。
微服务架构可以实现团队的自治。
更容易实验和采纳新的技术（对小型技术公司尤为重要）。
更好的容错性。
（服务间解耦，避免了相互影响）微服务架构的弊端当然，没有一项技术可以被称为“银弹”。
微服务架构也存在一些弊端：服务的拆分和定义是一项挑战。
分布式系统带来的各种复杂性，是开发、测试和部署变得相对困难。
当部署跨越多个服务的功能时需要有一定的沟通协调成本。
开发者需要思考到底应该在应用的什么阶段使用微服务架构。
（对架构师的考验）笔者建议单体架构是简单应用的不错选择，微服务架构通常是大型复杂应用的更好选择。
微服务架构可以使小型自治团队能够并行工作，从而加快软件开发的速度，但微服务不是银弹，它存在包括复杂性在内的诸多弊端。
我们需要的不仅仅是通过微服务架构来加速软件交付。
成功的软件开发还需要DevOps和小而自治的团队。
不过，还要记得考虑进微服务过程中的人性层面，需要考虑员工的情绪才能成功转换到微服务架构，毕竟在进行微服务转型的时候，是需要程序员做一些心理上的调整的。
欢迎关注笔者，每天分享架构干货。
