每个服务都是自包含服务，并且应实现单个业务功能。
什么是微服务？
-
一个小规模的开发人员团队就能编写和维护一个服务。
-
每个服务都是一个单独的基本代码，可由小型开发团队管理。
-
团队可以更新现有服务，而无需重新生成和重新部署整个应用程序。
-
这一点与传统模型不同，后者由单独的数据层处理数据暂留。
-
每个服务的内部实现细节均对其他服务隐藏。
-
服务无需共享相同的技术堆栈、库或框架。
除了服务本身，典型微服务体系结构中还会出现其他组件：
该组件通常是一种现成的技术（例如 Kubernetes），而不是自定义构建的内容。
客户端会调用 API 网关，网关再将调用转发到后端上的相应服务，而不是由客户端直接调用服务。
使用 API 网关的优点如下：
-
无需更新所有客户端，便可对服务进行版本控制或重构。
-
服务可以使用对 Web 不友好的消息传递协议，比如 AMQP。
-
API 网关可执行身份验证、日志记录、SSL 终止和负载均衡等其他跨领域功能。
优点
-
新功能可能会被搁置，要等到 bug 修补程序后才能进行集成、测试和发布。
-
而由于沟通效率更慢、管理开销更高且敏捷性更低，大型团队的工作效率往往更低。
-
如果不共享代码或数据存储，则微服务体系结构可将依赖项减到最少，使新功能的添加变得更容易。
-
团队可以选择最适合其服务的技术，并适当地使用混合技术栈。
-
单个微服务在不可用的情况下不会中断整个应用程序，但前提是所有上游微服务能够正确处理故障（例如，通过实施熔断机制）。
-
借助 Kubernetes 或 Service Fabric 等业务流程协调程序，你可将更高密度的服务打包到一台主机中，从而提高资源的利用效率。
-
在整体应用程序中，更新架构可能极具挑战性，因为应用程序的不同部分可能都要获取相同的数据，对架构进行任何更改都会带来风险。
挑战
下面是在开始使用微服务体系结构之前需要考虑的一些挑战。
-
每个服务更简单，但整个系统作为整体来说更复杂。
-
测试服务依赖关系也有一定难度，尤其是在应用程序快速发展之时。
-
这尤其适用于日志记录等跨领域功能。
-
应避免过于繁琐的 API，考虑使用序列化格式，并找到可以使用异步通信模式的地方。
-
如果可能，请采用最终一致性。
-
通常情况下，日志记录必须为单个用户操作关联多个服务调用。
-
多个服务可在任意给定时间更新，因此，若不精心设计，可能会遇到向后或向前兼容性问题。
-
请仔细评估团队是否具有成功使用微服务所需的技能和经验。
最佳实践
-
围绕业务域对服务建模。
-
避免共享代码或数据架构。
-
为每个服务和数据类型使用最合适的存储。
-
API 应对域建模，而不是对服务的内部实现建模。
-
耦合的原因包括共享的数据库架构和严格的通信协议。
-
将身份验证和 SSL 终止等跨领域操作分流到网关。
-
否则，网关会变成一个从属物，从而导致服务之间耦合。
-
两个服务之间的通信过于频繁可能是紧密耦合和低内聚的征兆。
-
使用复原策略可防止某个服务中的故障级联。