Go语言| 微服务的优与劣

微服务的优与劣

微服务是一场架构层面的变革，而 Go 由于其简单实用的语法、编译快、可执行文件小等特点，是微服务所依赖的底层基础设施常用语言，这也许会为 Go 开发者进一步学习提供一定的基础，但“千里之行始于足下”，如果不认真去学，一步一个脚印，知识也不会凭空而来。

微服务是未来软件开发的首选，以后每个开发、每个公司都会选择它，但我们都知道：“软件开发没有'银弹'”，一个事物，如果它的优势越明显，那么它的劣势也越明显，而且一般来说，它的劣势就是它优势的反面。

微服务优势可以总结有如下几点：

业务代码和技术代码分离

原先在框架内部的代码如负载均衡、服务注册、熔断限流、链路追踪等等，均沉淀到技术底层，对业务的开发人员透明化，业务开发人员可以更好的思考用什么语言、什么存储去实现服务逻辑，而不必受到框架的限制。

快速迭代，稳定发布

微服务专注于一项功能，且有清晰的接口边界。这样，无论是迭代升级，还是完全推到重来，改造的成本都比较小。而且，由于底层调度系统的支持，发布服务时再也不用等到凌晨用户量少的时候偷偷更新一下，发布变得更快速更稳定。

简化开发步骤，提升效率

微服务化以后，对于普通开发人员而言，负担是更轻了的，技术代码的抽离使底层技术成为黑盒，开发新服务只需要一个轻量的框架，快速配置一下即可马上开始开发，梦回 SpringBoot 时代。

而微服务的劣势，同样也是三点：
沉重的技术架构带来的考验

代码的分离势必导致团队内对底层服务的了解更少了，即使团队内有人愿意去学习，一方面可能了解的人不愿意花心思科普；另一方面自己也有沉重的业务开发负担，精力不够。

所以有关微服务的书籍都会不约而同的提到“康威定律”，就是要求这些分离出去的技术设施需要独立团队维护。自从阿里提出“中台化”战略后，这些基础设施也有高大上的名字：“技术中台”。

但理想很丰满，现实很骨感。个团队在中小型公司存活的概率不大，一方面这些设施的建设是长期工程，短期难见成效；另一方面，这个团队在内部推行新设施的阻力也是比较大的，容易遭到业务侧的反对。

可是这个团队无法成立，微服务就只能沦为拆服务的游戏。

DevOps 的要求

微服务同样对运维团队提出了更高的要求，也就是现在常听的“DevOps”。原先发布可能就是丢个包上去就行，那些“build once , run anywhere”什么的口号都是广告，实际上普通的公司也没那么多的平台需求。

现在发布要搭建一套自动化发布流，与“技术中台”团队有更多的重合部分。实际上问题和“技术中台”团队碰到的差不多，效益和推广问题。

普通开发者能更快的开发程序，关注更少的架构侧的变化，对公司是好事，对个人不见得是好事。在优化基础设施的过程中巩固自己的知识，能通过学习改变自己。