[微服务] 微服务Bad Smell 的定义

On the Definition of Microservice Bad Smells

翻译，原文出处——Taibi D, Lenarduzzi V. On the Definition of Microservice Bad Smells[J]. IEEE Software, 2018, vol 35(3):56-62.

背景

在非同行评审文献和实践者谈话中提出的主要陷阱——

Bad Practice	Descriptions
Timeout	The service consumer cannot connect to the microservice.
I Was Taught to Share	Sharing modules and custom libraries between microservices.
Static Contract Pitfall	Microservice APIs that aren’t versioned, possibly causing service consumers to connect to older versions of the services.
Mega-Service	A service that is responsible for many functionalities and should be decomposed into separated microservices.
Shared Persistence	Using shared data among services that access the same database.
Data Ownership	Data should not be directly shared among different services. Microservices should own only the data they need and possibly share it via APIs.
Leak of Service Abstraction	Designing service interfaces for generic purposes and not specifically for each service.
Hardcoded IPs and Ports	Hard-coding the IP address and ports of communicating services, therefore making it harder to change the service location afterward.
Not Having an API Gateway	Services directly exposed to the outside and connected to each other.
Lust	Using the latest technologies.
Gluttony	Using too many different communication protocols such as HTTP, protocol buffers, Thrift, etc.
Greed	Services all belonging to the same team.
Sloth	Creating a distributed monolith due to the lack of independence of microservices.
Wrath	Blowing up when bad things happen.
Envy	The shared-single-domain fallacy.
Pride	Testing in the world of transience.

问卷访谈的方法

我们在经验丰富的开发人员中进行了调查，收集了微服务体系结构中的不良做法以及他们如何克服这些不良做法。我们==采用结构化的方式收集信息，并通过结构化程度较低的问卷，询问受访者开放式问题以获得更多相关信息==（例如,迁移到微服务时可能遇到的问题）。

调查问卷最重要的目标之一是了解哪些不好的做法对系统开发有最大的影响，并且从业人员正在应用哪些解决方案来克服这些问题。因此，我们要求被访者按照0到10的等级对每个不好的练习进行排序，其中0表示“坏习惯是无害的”，10表示“坏练习是非常有害的”。此外，我们澄清说，只有排名不好的做法有真正的意义。

例如，Hardcoded IPs不良实践的值为7，
Shared Presistence的值为5,表明硬编码IP被认为比共享持久性更有害，但7和5的个别值本身没有意义。有害的做法是为从业者带来了一些问题的做法，例如增加维护工作量，减少代码可理解性或增加不完善性。

根据我们旨在收集的信息，这些访谈基于四个部分的调查问卷：

• 个人和公司信息。受访者的角色和公司的应用领域。

• 开发基于微服务的系统的经验。开发微服务的多年经验。要求这个问题来确保数据仅来自于收集
  老练的开发者

• 微服务不良做法的危害。在基于微服务的应用程序的开发和维护期间创建了一些问题的实践列表，根据其在10点李克特量表上的危害性排名。此外，对于每一种做法，我们都要求从业者报告其产生的问题以及他们认为有害的原因。对于这个答案，面试官没有提供任何提示，让参与者报告他们在开发或维护基于微服务的系统时遇到的不良做法。此外，为了避免影响受访者，我们要求他们列出他们自己的不良行为，而不向他们提供以前由从业者发现的陷阱清单.

• 糟糕的实践解决方案。对于确定的每一个不好的做法，参与者如何克服它。

所有采访都是亲自进行的。我们知道在线问卷可能会产生更多的答案。然而，我们认为面对面访谈对于收集非结构化信息更加可靠，因为它们允许与受访者建立更有效的沟通渠道，并且更容易解释开放式问题的答案。

被访者被要求提供个人答案，即使他们在同一组工作。这使我们能够更好地理解不同的观点，而不仅仅是公司的观点。采访的目的是每个参与者需要15分钟。然而，公开讨论的时间比预期的要长，每个参与者平均需要21分钟。

我们从实践者活动和会议的参与者中进行访谈人员的选择。也就是说，我们采访了2016年国际敏捷软件开发大会（XP 2016）的21位参与者，2017年敏捷软件开发微服务研讨会的7位参与者，17位参加者为2017年的2017届毕业生，31个参与了于2017年1月至7月在意大利和德国举行的几个小型开发者活动。

在采访中，我们首先向参与者介绍了我们的目标。然后，我们问他们是否至少有两年开发微服务系统的经验，以节省时间，避免打扰没有经验的从业者。

调查结果

• Participants composition:

  • 72 interviews with participants belonging to 61 different organizations

  • Work Position: 36% - software architects, 19% - project managers,
    38% - experienced developers, 7% - agile coaches

  • Work Place: 28.57% - banks, 28.57% - companies that produce and sell only their own software as a service, 23.81% - consultancy companies specializing in migration to microservices, 9.52% - IT department of public administrations, 9.52% -telecommunications companies

  • Working Years: 17% - more than five years, 60% - three to four years, 23- two to three years.

• 265 different bad practices with the solutions they had applied to overcome them -> open and selective coding process -> 11 microservice smells

Catalog of microservice smells

Microservice smell	Desc/Detection/Problem it may cause (P)/Adopted solutions (S)
API Versioning	A lack of semantically consistent versions of APIs
Cyclic Dependency	The existence of cycles of calls between microservices -> Refine the cycles according to their shape,and apply the API Gateway pattern.
ESB Usage	An ESB adds complexities for registering and deregistering services on it.
Hard-Coded Endpoints	S: Adopt a service discovery approach.
Inappropriate Service Intimacy	S: Consider merging the microservices.
Microservice Greedy	Teams tend to create new microservices for each feature, even when they are not needed. Common examples are microservices created to serve only one or two static HTML pages.
Not Having an API Gateway	Microservices communicate directly with each other. In the worst case, the service consumers also communicate directly with each microservice, increasing the complexity of the system and decreasing its ease of maintenance.
Shared Libraries	P: Microservices are tightly coupled together, leading to a loss of independence between them. Moreover, teams need to coordinate with each other when they need to modify the shared library.
Shared Persistency	P: This smell highly couples the microservices connected to the same data, reducing team and service independence.
Too Many Standards	P: Although microservices allow the use of different technologies, adopting too many different technologies can be a problem in companies, especially in the event of developer turnover.
Wrong Cuts	Microservices are split on the basis of technical layers (presentation, business, and data layers) instead of business capabilities.

总结

1. 微服务在开发和维护过程中有其独特的问题，开发者可以从文中总结吸取经验，避免不好的实践；

2. 软件架构还是很重要的，要对微服务有很深的理解才能做出正确的系统层次的决策；

3. 从单体应用到微服务应该是去识别可以从单体中隔离出来的独立业务流程，而不仅仅是对不同web service的特征提取；

4. 微服务之间的访问，包括私有数据和共享库，都必须被小心地分析；

5. 一个一般性规则，当开发者需要知道其他服务的内部细节或者一个服务的改动波及到另一个服务，那么很有可能是微服务在设计上是不合理的。