微服务微服务
微服务是提供单一业务功能的服务。从技术角度来看，这是一个小而独立的过程。与流程概念类似，它可以自己启动或销毁，并拥有自己的独立数据库。

复杂的软件体系结构由许多小型独立（具有自己的端口）微服务组成。这些独立处理组件之间的通信是通过与语言无关的API。简单协议具有同步RMI/RPC和RESTful Web。服务，异步消息推送和Reactive。

这些模块化方法使公司能够跨多个开发团队分布项目细分，提供跨不同业务部门的灵活性，有助于延长项目生命周期并加快项目开发的完成。
每个微服务组件都有自己分配的存储内存和CPU资源，这使得硬件利用率更易于优化和跟踪，尤其是在基于云的Pass环境中，开发团队可以使用他们喜欢的技术，任何语言，只要确保微服务是交互式的，最终的应用程序可以组合在一起。
当采用微服务架构降低管理复杂性时，更新其中一个微服务组件通常不会引起连锁反应，因为微服务松散耦合。
目前使用微服务的公司有：Netflix Twitter亚马逊网络服务（AWS），谷歌，eBay等。

由于在基于云的基于主机的环境中部署了许多应用程序和服务，因此微服务架构将严重依赖容器技术。容器隔离了微服务进程并将应用程序划分为小实例。这些容器很小。该实例具有自己的端口和虚拟化环境。

广泛使用的容器技术是Docker，这是一个基于Linux的开源实现，由Canonical，Red Hat和Parallels等许多软件公司提供支持。 PaaS服务支持包括Google App Engine，Red Hat Open Shift和VMware的Cloud Foundry。
微服务架构不仅仅是传统服务变得越来越小。微服务的两个显着特征是：微服务本身是无状态的；
微服务之间几乎没有变量共享。
可以想象，如果可以共享微服务，就存在两个问题：因为共享数据库是一个统一的数据库，所以微服务团队需要合作。如果分享不会带来沟通成本，它不会破坏团队。这种共享数据库也可以考虑，但这种情况很少，大多数团队因为共享问题而打破了独立性；此外，如果微服务使用Docker打包在一个容器中，这些容器可能会部署在不同的基础设施和D部署灵活。它是一个云本地应用程序，共享数据库属于底层基础设施，这明显增加了部署的难度。

另外，无论是rpc/rmi还是http/restful，传统服务之间的通信都是同步的，微服务之间的通信最好是异步的或响应的，即异步的。根据FLP原理，网络默认值不可靠。在网络拥塞的情况下，RPC将爆炸。此后，监测不能从根本上解决这个问题。它需要从cap定理的角度进行平衡，引入事件驱动或pub/sub消息模式。在保证数据最终一致性的同时，提高了网络容错能力。灵活的事务处理是微服务环境的主要选择。

传统的服务变成了一块铁。这通常是因为事务处理需求。一个服务方法有很多代码，需要固定在同一个事务边界中。尽管这会带来高一致性，但可扩展性较差，因为同一事务边界内的操作无法分离为多个微服务。因此，微服务的使用必须积极地接受最终的一致性，并对分布式系统和cap定理有一定的理解。当然，当有多个微服务呼叫时，这些都是必须考虑的情况。由于微服务是小而具体的，它们可以通过组合来替换共享的继承思想，并且代码容忍度有点重复。
微服务架构需要以下条件：
基本监测测量与健康检查
分布式日志跟踪
对于每个服务，不仅是隔离代码，还包括build + test + package + submit中的整个链接。
清楚地定义每个服务的上游和下游，编译时间和运行时依赖性。
掌握如何构建，公开和维护良好的API和合同。
尊重黑白和f/w兼容性，即使您可能不是您正在生产的服务的消费者。
良好的单元测试和更多可读性
请注意微服务和模块与库包之间的区别，以及分布式单片整体，协作版本发布和数据库驱动程序继承。
了解基础设施的自动化
需要基于CI/CD持续集成/持续交付的基础架构
服务部门：基于业务能力定义服务范围
基于域驱动设计中子域概念定义服务范围
通讯方式：
使用基于RPC的同步通信
使用异步消息传递进行服务间通信
外部API：
API网关-为每种类型的客户端提供访问服务的唯一接口
前端后端-为每种类型的客户端提供单独的API网关
数据管理：
每个服务都有自己的专用数据库接口
在服务之间共享同一数据库
使用事件维护服务事件跟踪/CQR之间的数据一致性
运行和维护监控：
发现服务：通过第三方模块将服务实例信息注册到服务注册表的过程
分布式跟踪新的-为服务代码中的每个外部访问分配一个唯一的服务标识符，并将此标识符传递给跨服务访问，以跟踪分布式触发器
断路器-当远程服务返回的失败率超过某个阈值时，客户端代理（如API网关）将立即向远程服务返回失败消息。

• 上一篇: 蓝盟IT外包，元宇宙：四梁八柱是什么
  下一篇: SaaS和人工智能的未来是什么？

• 分享到：