The core capabilities of microservice 微服务的核心功能

The core capabilities are explained as follows:
Service listeners (HTTP/messaging): If microservices are enabled for a HTTP-based service endpoint, then the HTTP listener is embedded within the microservices, thereby eliminating the need to have any external application server requirement. The HTTP listener is started at the time of the application startup. If the microservice is based on asynchronous communication, then instead of an HTTP listener, a message listener is started. Optionally, other protocols could also be considered. There may not be any listeners if the microservice is a scheduled service. Spring Boot and Spring Cloud Streams provide this capability.
Storage capability: The microservices have some kind of storage mechanisms to store state or transactional data pertaining to the business capability. This is optional, depending on the capabilities that are implemented. The storage could be either a physical storage (RDBMS such as MySQL; NoSQL such as Hadoop, Cassandra, Neo 4J, Elasticsearch, and so on), or it could be an in-memory store (cache like Ehcache, data grids like Hazelcast, Infinispan, and so on)
Business capability definition: This is the core of microservices, where the business logic is implemented. This could be implemented in any applicable language such as Java, Scala, Conjure, Erlang, and so on. All required business logic to fulfill the function will be embedded within the microservices themselves.
Event sourcing: Microservices send out state changes to the external world without really worrying about the targeted consumers of these events. These events could be consumed by other microservices, audit services, replication services, or external applications, and the like. This allows other microservices and applications to respond to state changes.
Service endpoints and communication protocols: These define the APIs for external consumers to consume. These could be synchronous endpoints or asynchronous endpoints. Synchronous endpoints could be based on REST/JSON or any other protocols such as Avro, Thrift, Protocol Buffers, and so on. Asynchronous endpoints are through Spring Cloud Streams backed by RabbitMQ, other messaging servers, or other messaging style implementations such as ZeroMQ.
API gateway: The API gateway provides a level of indirection by either proxying service endpoints or composing multiple service endpoints. The API gateway is also useful for policy enforcements. It may also provide real time load balancing capabilities. There are many API gateways available in the market. Spring Cloud Zuul, Mashery, Apigee, and 3scale are some examples of the API gateway providers.
User interfaces: Generally, user interfaces are also part of microservices for users to interact with the business capabilities realized by the microservices. These could be implemented in any technology, and are channel- and device-agnostic.

核心能力解释如下：
服务侦听器（HTTP /消息传递）：如果为基于HTTP的服务端点启用了微服务，则HTTP侦听器嵌入在微服务中，从而无需满足任何外部应用程序服务器要求。 HTTP侦听器在应用程序启动时启动。如果微服务基于异步通信，则启动消息侦听器而不是HTTP侦听器。可选地，还可以考虑其他协议。如果微服务是预定服务，则可能没有任何监听器。 Spring Boot和Spring Cloud Streams提供此功能。
存储能力：微服务具有某种存储机制，用于存储与业务能力相关的状态或事务数据。这是可选的，具体取决于所实现的功能。存储可以是物理存储（RDBMS，如MySQL; NoSQL，如Hadoop，Cassandra，Neo 4J，Elasticsearch等），也可以是内存存储（像Ehcache这样的缓存，像Hazelcast这样的数据网格， Infinispan等等）
业务能力定义：这是实现业务逻辑的微服务的核心。这可以用任何适用的语言实现，例如Java，Scala，Conjure，Erlang等。实现该功能所需的所有业务逻辑将嵌入微服务本身。
事件溯源：微服务向外部世界发送状态变化，而不必担心这些事件的目标消费者。这些事件可以被其他微服务，审计服务，复制服务或外部应用程序等使用。这允许其他微服务和应用程序响应状态变化。
服务端点和通信协议：这些定义了供外部消费者使用的API。这些可以是同步端点或异步端点。同步端点可以基于REST / JSON或任何其他协议，例如Avro，Thrift，Protocol Buffers等。异步端点是通过RabbitMQ支持的Spring Cloud Streams，其他消息传递服务器或其他消息传递方式实现（如ZeroMQ）。
API网关：API网关通过代理服务端点或组合多个服务端点来提供间接级别。 API网关对策略实施也很有用。它还可以提供实时负载平衡功能。市场上有许多API网关。 Spring Cloud Zuul，Mashery，Apigee和3scale是API网关提供商的一些例子。
用户界面：通常，用户界面也是微服务的一部分，用户可以与微服务实现的业务功能进行交互。这些可以在任何技术中实现，并且与通道和设备无关。