开发人员学习微服务架构最容易犯五个的错误

当我们学习一项新技术或工具时，我们经常会依赖于我们以往的项目中经验。然而，当我们学习最近很热门的微服务时，我们以往的经验可能却都不管用了。

在本文中，我们将讨论专业开发人员在学习微服务主题时最容易犯的五个主要错误。

错误#01 -将SOA和微服务混淆。

尽管SOA和微服务都是系统架构的一种，但这两个有很多不同之处：

SOA

它的一般是通过一种方式（单实例，ESB等）来连接现有的应用程序。

必须通过ESB在端点之间的连接和消息

ESB中公开的服务应该使用特定的语言编写，并且主要遵循SOAP协议(无论是否使用WS* stack)或REST，使用HTTP协议。

由于需要编码和解码，在高负载的情况下交换信息代价高昂。

垂直进行扩展(扩大)

ESB作为单个故障点

由于应用程序EndPoint和ESB中介本身的依赖关系，很难将其部署到MSA(微服务样式体系结构)

服务是在其他服务执行和使用其合同之前进行注册的。

Microservices

它的方法是创建一个单独的应用程序，自部署，它可以在一个独立的环境中运行，并且有自己的数据库。

服务之间的连接是精心设计的-通过这种方式，微服务可以对所接收的特定事件作出响应。

可以用任何可用于创建服务的编程语言编写微服务Java. Python, JavaScript, .NET。

只需要遵循REST接口即可，可以使用谷歌Protobuf、Twitter Finagle等二进制协议。

对应于我们单体应用系统的功能特征

容错

水平扩展(扩展)

易于部署，CD/CI

微服务在称为API网关的实体中注册，并被其他微服务自动发现。

错误#02 -“如果我使用REST方法，我已经有了微服务”

在微服务中，REST方法只是MSA的主要属性之一。对于要标记为微服务解决方案的应用程序，应该具有12因素方法学描述的所有特征。

代码库：一个版本代码，多次分发

依赖关系：显式声明和隔离依赖项

配置：在环境中存储配置。

支持服务将支持服务视为附加资源

构建、发布、运行：严格分开构建和运行阶段。

流程：将应用程序作为一个或多个无状态进程执行

端口绑定：通过端口绑定导出服务

并发性：通过流程模型扩展

可处理：快速启动和快速关闭，使健壮性最大化

x Dev /刺激平价

Dev/prod parity：开发，部署和生产尽可能保持一致

日志：将日志处理为事件流

管理流程：将管理和管理的任务作为一次性的过程

错误#03 -微服务可以在同一个容器上运行。没问题,对吧?

理论上是的。不幸的是,这正是一个问题。

Microservices应该:

在其环境中完全独立运行，并拥有所有所需的资源(松散耦合)

能够独立伸缩。

能够独立地部署。

能够被追踪到

能够被其他微服务自动发现

这些都是保持正确的可伸缩性、容错和TTM(上市时间)的必要条件。

错误#04 -所有的微服务都应该用相同的编程语言编写

一旦微服务在不同的容器上运行并公开了抽象其底层技术，就不需要用一种特定的编程语言实现所有的微服务。

考虑到这一点，您可以拥有更小的团队，每个团队都具有业务funci向性和编程语言的专门知识，从而可以独立地简化业务解决方案的演变。

错误#05 -微服务顾名思义，应该是小的

微服务中的微服务表示目前存在于单块应用程序中的业务功能，称为“所有解决方案”，这些解决方案具有多个功能问题，需要解决一个巨大的业务问题。

然后将这个业务问题分割成更小的部分(微服务本身)，以便轻松组合并有效地响应所有业务事务中可能出现的所有请求和业务需求。