微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务,而红帽说API应该是重点。
微服务可以在"自己的程序"中运行,并通过"轻量级设备与HTTP型API进行沟通"。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构(在现有系统中分布一个API)区分开来。在服务公开中,许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能,那么就必须缩小进程范围。在微服务架构中,只需要在特定的某种服务中增加所需功能,而不影响整体进程。
微服务系统架构集成与服务规划
微服务集成
微服务的集成做到好,可以保持自治性、可以独立发布修改和发布。
1、集成原则
1)避免破坏性修改
服务的一些修改不能导致该服务的消费方发生改变。
2)保证API与技术的无关性
3)保证API的易用性
4)隐藏内部实现细节
2、同步与异步
同步:调用方发起远程服务调用后,调用方阻塞自己并且等待服务方的返回。
异步:调用方不需要等待服务方返回,甚至可能不关心这个操作完成与否。
3、编排与协同
编排:同步调用一组服务,等待各个服务的返回结果。优点知道业务流程中每一步跨服务调用结果,缺点容易承担太多的调用,太耗时,导致调用方的不稳定性。
协同:异步调用一组服务或服务调用加入队列中,降低服务之间的耦合度,带来的额外工作业务流程跨服务的监控,不过可通过消费方处理完成后,回调服务方告知处理结果。
4、版本管理