对于微服务的思考

在我的2017年计划里，提到想去探讨微服务对于新兴业务和初创公司的价值，是否有指导作用。

经过几个月的折腾和摸索，基本得到了想要的结论，首先列在这里。

1. 对于初创公司和业务，部署微服务基本上是掉坑里了。

2. 对于大公司的新兴业务，有基础技术栈和业务栈的积累，才是微服务的生存地。注意这里有技术栈和业务栈两部分内容。

微服务的边界

推荐王垠的这篇博客现实理想主义者，代码的首要目标是“解决问题”，其次才是“优雅”、或者可扩展性，或者其它的什么因素。

问题：微服务能够推动业务快速迭代？

答案是看情况。

对于初创公司而言，很多时候面临的不确定性太大，远远不是微服务就能够解决的，实际上没有任何工具（微服务也只是个工具）能解决所有的不确定性问题，所以很多初创公司宁愿用excel和邮件来“低效”的处理很多问题，也不会去做类似于CRM这种系统。这是很明智的一种行为，个人感觉也是最合理的。

对于大型公司，微服务是新兴业务增长的重要根基。主要包括两个方面：技术上，微服务催生的基础服务工具，例如通信中间件、DevOps、监控和跟踪、统一日志、配置中心、自动缩扩容等，能够让开发人员更专注于业务的同时，即使不具有大并发量、高可用、负载分析等技术栈，也能够做出高质量的服务。业务栈上，微服务的存在意味着公司内部的服务都会是定义良好的、功能专一的接口，可以通过通信中间件低成本的调用公司现有的服务。

微服务之外

除了服务本身之外，小公司的关键在于“人”，合适的人才是业务支撑的关键。这个人需要自己去关心所有的技术问题。服务监控、异常日志、服务可用性、负载评估、甚至DB压力评估、自己搭建发布系统等。有些公司初创团队招聘的小同学服务挂掉了一周都不知道，这暴露了太多问题了，小同学不关注服务本身是一个问题、招聘同学甚至问题更大。

而对于大公司，很多某个业务本身的同学就容易成为一个的“螺丝钉”。虽然大公司的招聘极其严格，但是对于其精细的管理和大量的基础服务，这些同学是over qualified。大公司完善的流程和大量的基础工具让一个即使比较“傻”的人也可以写出可用性比较高的服务，是否去研究底层的实现基本上就看这个人自己的好奇心和自驱力。

微服务架构可能是不适合你的，但个人认为对于架构的探索不能停止。对于微服务的探索至少还可以让我们获得两个东西：

一，理解trade off和没有银弹。

微服务只是一种形式，本质上作为后端开发，是要提供高质量的服务。而对形式的分析可以让人更好的看到灵活性、可用性、人力成本之间的trade off。没有标准化微服务流程的服务，可用性不如有规范流程的服务，但灵活性更高。有规范化微服务流程，对于人力的要求没那么高，而无流程的服务，必须依赖于高质量的人来保证。

二，大量高质量的轮子

微服务的部署中用到的很多组件本身都是业界高质量服务的典范，微服务的部署者选择它们作为自己服务的模块不是偶然。对于这些轮子的理解和使用，是一个对架构感兴趣人员的基本素质。