都在谈微服务，那什么是好的服务？

微服务流行的这几年，都在说微服务，聊架构、聊优势，就好像没有好好聊一下什么是服务，怎样的服务算是好服务。作为一个程序员，我们会用很多第三方工具类，你会发现有些工具它面向的比较底层，它的函数很多、每个函数提供的入参也很多；有些工具比较接近业务，会提供给使用者直接能用的、很简单的函数。这些情况的存在是很正常的，底层的函数要考虑到各种各样的场景要比顶层的函数多。

如果给你两个都能满足你需求的工具，一个底层一个顶层，你肯定会选择顶层。假设你现在要取消手机上的某个增值服务，你是打个官方客户电话告诉她要取消，她马上给你操作好；还是去百度搜一搜怎么取消，再根据方案一个个试，可能发个短信去取消，也可能要登录某个网站进去某个菜单去取消？显然是前者更爽。这就看得出区别了，虽然都能服务于你、满足你的需求，但有好坏之分。有的政府部门很高效，办事情直接明了；有的则在踢皮球、故意刁难；都是在为人民服务，你说有没有好坏之分呢？

那么问题来了，什么样的服务是个好的服务？我认为应该是：

1. 能满足你的需求，这是前提
2. 你只需要表达需求，而非步骤（你不用告诉对方应该怎么做）
3. 最少的信息输入，有用的信息输出（你只需要告诉对方最少的必要的信息，对方只返回给你有用的信息）

当然好的服务可能成本比较高。举个例子，交通卡充值，在地铁站有两种方式：

1）人工服务，表达需求是：充值。 输入是交通卡和钱。 输出是充值好的交通卡和小票

2）自助服务，在机器上点击充值，根据提示放入交通卡，选择充值方式，例如微信支付，打开手机微信，扫描支付，等待机器充值完成，拿出交通卡和小票

显然，如果不考虑成本或等待时间的话，人工服务对消费者来说是最好的。

那如果上面的判断没有明显的差别，那还能怎么判断一个服务更好？

1）客户需要操心的事情越少越好。

这里包括客户的心智，例如充值服务，手工服务的话，小孩和老人都可以使用，但是自助就不一定行。

操心的事情还包括：

• 这个卡上次欠费了没补扣到，怎么处理？自助服务可能直接让去人工处理了
• 这个卡读磁好像不太好，机器没识别到
• 这个卡被机器吞了!

2）客户花费的时间越少越好。

人工服务为什么值钱？因为它带了智能元素。它可以处理程序之外的事情。

那自助服务就没有优势了吗？当然不是，它的优势就是低成本 + 易扩张 + 24小时不间断。

所以，现阶段，很多都是人工+自助的形式，就是因为它们谁也替代不了对方，而最好的方式就是利用它们的优点，平衡好。

2021更新

1. SQL为何这么流行？大数据最终也是以SQL的形式来操作。

因为SQL表达的是要什么数据（要啥就告诉啥，没有多余的信息返回）、查询什么条件就可以了，不需要告诉服务器额外的信息、也不要告诉操作过程。

它符合好服务的特征。

2. 为何helm charts是部署表达的最终形式？

使用k8s时，我们会编写k8s的yaml进行部署，每个kind一个yaml。对于一次部署一个MySQL实例，可能需要Deployment、Service等多个kind，因此就会有多份yaml文件，因此还需要一个文件夹把这些yaml放一块。当又要部署一个MySQL实例时，又得复制出这样一堆yaml文件，可以发现，这两堆yaml文件中，有大量的信息是重复的，而它们不同的信息，恰好是最终用户部署一个MySQL实例时需要表达的信息：

mysql的版本
root账号的密码
数据持久化路径
暴露端口

没有其它信息了。

而helm charts就做到这种方式了，只需要用户填这几个信息，一个mysql实例就可以跑起来了。更复杂的如clickhouse、elasticsearch等都只需要用户填写用户需要指定的信息，不用做额外的事项，就可以秒起一个实例。

其实我们可以发现，有些方式是最终的形式 。例如面向最终端消费者的操作界面，应该就是当前科技水平下的最终形式。如果科技水平更高，是否会出现通过人工智能、意识控制等更为最终的形式，还是可能的。

在互联网形态下，web和app是普通用户的最终的展现形式。我们应该尽量将功能以这两种形式提供，而不是登录机器去敲命令或编辑复杂的配置。