蓝盟IT外包小贴士，来喽！
1 .单一责任原则
与代码一样，类只有一个更改原因，因此微服务必须以相同的方式建模。 建立臃肿的服务可能会改变多种商业环境。 这是个不好的方法。
例如：假设您正在构建订购披萨的微服务。 根据各自支持的功能(InventoryService、OrderService、PaymentsService、UserProfileService等)
DeliveryNotificationService等)构筑以下组件。 Oracle inventory service只有一个API可以获取和更新披萨类型和浇口库存。 同样，其他API也具备这些功能。
2 .为微服务有单独的数据存储
如果所有微服务都使用共享的整个数据库，则无法实现微服务的目的。 数据库更改或停机会影响使用数据库的所有微服务。 选择适合您微服务需求的数据库，自定义您要维护的数据的基础架构和存储，并将其专用于微服务。 理想地，需要访问此数据的其它微服务只能从具有写访问权限的微服务公开的API访问。
如果微服务依赖于另一个系统提供响应，并且该系统需要始终作出响应，则整体响应SLA可能会受到影响。 为了避免这种情况并加快响应速度，简单的微服务最佳做法是使用断路器超时外部调用并返回默认响应或错误。 断路器模式在以下参考文献中进行说明。 这将隔离服务所依赖的故障服务，并保持微服务的运行状况，而不会引起级联故障。 您可以选择使用Netflix开发的热门产品，例如Hystrix。 这比使用HTTP CONNECT_TIMEOUT和READ_TIMEOUT的设置更好。 这是因为不会启动超出设置范围的线程。
使API网关能够预先执行这些操作，而不是系统中的所有微服务都能够执行API验证并请求和响应日志记录和限制，这有很多价值。 调用微服务的客户端将连接到API网关，而不是直接调用服务。 这样可以避免对微服务的所有这些调用，隐藏服务的内部URL，从而使API网关能够灵活地将通信重定向到新版本的服务。 这是必要的，因为第三方可以在访问服务时限制传入流量，并在API网关到达微服务之前拒绝来自API网关的未授权请求。 您也可以使用其他API网关从外部网络接受流量。
中文
电话咨询
微信咨询
公众号
