我对微服务的一些看法

随着微服务的流行，微服务好像成了解决一切问题的银弹。现在很多人都在谈论微服务以及微服务的实现技术，都想将这些技术应用到自己的项目当中去。这样好吗？很多人对微服务并不了解，就是从其他人的口中或某篇吹嘘微服务的博客当中得到某些概念及被告知的各种好处，就想着怎么应用自己的学习的技术。就像一个设计模式的初学者，学了一些设计模式，就挠着头想着将所学应用到工作当中去，而不管不顾当前项目的情况，还感觉这样很酷。

有些人将服务层分离为一个独立的系统，这一层仅包括一个业务逻辑处理，数据访问等功能，然后将视图层分为PC端，微信端，Android端，IOS端等多个系统，然后通过视图层调用服务层实现相应的功能，这是微服务吗？这样做有什么好处呢？很多人说这样重用了服务层呀，减少冗余的代码。要么视图层展示的数据完全一致，要么需要在服务层进行相关的逻辑判断，根据调用服务的标志返回不同的数据；要么创建一个新的服务。这样有减少代码吗，提供可读性了吗？提高了代码的可维护水平了吗？或者提升了系统的发布效率了吗？好像都没有，但是不少团队你就采用了，他们宣称他们采用了微服务，更好解决了系统的各种问题。

如果你的应用的活跃用户数比较少，也就是几万，有的甚至只有几千，每天访客也就几千上下浮动，我这样说，可能还高估了某些应用的用户和应用的数据量，而且系统功能也不复杂，但是他们就是要把这样的应用做成拆分为多个服务，美其名未雨绸缪。但是从组织的角度看，有什么好处呢？什么也没有，一个更加复杂的系统，这样的系统更难以维护，而且还浪费了服务器资源，因为一个单独的系统拆分成了多个系统，将会要求更多的服务器资源。此外开发，测试的难度也大幅增加，特别问题的诊断所花费的时间，也大大增加了。所以我们在估计用户增长量和功能规模时，要理性些，不要去对标一些幸运儿。如果一年用户量有个2-4倍增长，已经非常了不起的成就了，都是撞了大运气。

如上所述，那是微服务吗？我认为不是。微服务的一个重要特征就是根据业务功能来拆分，拆分后的每个服务管理自己的数据，这就明显区别于按层划分服务和数据的统一管理。有的人说，你管它是不是微服务，只要它解决了问题。是的，问题是解决了，只是采用了一个更加复杂，代价更高的方案而已。所以我认为很多人想要应用微服务，至少要去了解何为微服务，微服务有哪些特征，了解它的适用场景。要知道微服务也是有其代价的，它更加复杂，运维成本更高，对人员的技术水平要求也更高。它不是解决所有问题的最佳方案。

现在大家都推崇微服务实现技术，比如Spring cloud，Dubbo，zookeeper，Kafka等，这些技术很重要。他们存在的目的就是为了简化微服务的开发，而不是其他，因为在不采用这些技术的情况下，你也能够实现微服务，你可以直接选择http实现服务之间的通信，你可以将轮询和容错的逻辑硬编码在代码中，只是这样增加了代码的复杂性，减低的应用的灵活度，所以这些技术都是来解决问题的，它们并不是微服务的难点，如果这些技术非常难学且难于实施，那他们倒是成了难点。我认为微服务的难点还是在于应用的拆分，服务接口的设计，应用的监控以及问题诊断等，所以在这个过程当中，理解领域知识非常重要，另外在设计微服务过程当中，很容易忽略服务的监控和日志功能，没有监控的功能，让人很难及时发现问题，没有日志，查找和诊断问题就成了难题了。

个人想法，可以拍砖。