Kubernetes, Kafka微服务架构模式讲解及相关用户案例
本帖最后由 pig2 于 2018-7-5 17:03 编辑问题导读
1.微服务有什么特点？
2.本文介绍了哪些案例？
3.你认为事件驱动的微服务、容器、Kubernetes和机器学习结合可以带来哪些发展？
static/image/hrline/line7.png
随着当今业务和技术的快速变化，开发人员，数据科学家和IT运营部门正在共同构建具有新技术和动态架构的智能应用程序，因为它们具有灵活性，交付速度和可维护性。 这篇文章将介绍有助于进化架构的技术：containers，Kubernetes和Kafka API。 然后我们将看一些Kafka架构模式和用户案例.
容器架构
容器简化了从开发到部署的过程，无需担心可移植性或可重复性。 开发人员可以将应用程序及其执行应用程序所需的所有依赖项，库和配置文件打包到容器镜像中。 容器是可运行的镜像实例，可以部署到任何位置：笔记本电脑，本地服务器或云端。
与虚拟机相比，容器具有类似的资源和隔离优势，但重量更轻，因为容器虚拟化操作系统而不是硬件。 容器更便携，更高效，占用更少的空间，使用更少的系统资源。
Kubernetes 架构
Kubernetes提供了一个配置，自动化和管理的平台：
[*]容器的智能和平衡调度
[*]容器的创建，删除和移动
[*]易于扩展容器
[*]监测和自我修复能力
Kubernetes集群由至少一个管理集群的主节点和多个工作节点组成，其中容器化应用程序使用Pod运行。 Pod是一个或多个容器的逻辑分组，它们一起安排并共享资源。 Pod允许多个容器在主机上运行并共享资源，例如：存储，网络和容器运行时信息。
主节点以这种方式管理集群：
[*]API服务器解析YAML配置并将配置存储在etcd键值存储中。
[*]etcd存储并复制当前配置和集群的运行状态。
[*]调度程序调度工作节点上的pod。
[*]controller 管理器管理非终止控制循环的状态，例如pod副本。
微服务架构风格是一种将应用程序开发为围绕特定业务功能构建的一组小型企业可部署服务的方法。 微服务方法与容器和Kubernetes完全一致。 通过跨多个节点部署服务，您可以获得模块化，广泛的并行性和经济高效的扩展。 微服务模块化有助于独立更新/部署，并有助于避免单点故障，这有助于防止大规模中断。
MapR Data Fabric包含一个本机集成的Kubernetes卷驱动程序，可提供持久存储卷，以访问本地，跨云和边缘的任何数据。 有状态应用程序可用于生产用例，机器学习管道和多租户用例的容器中。
事件驱动的微服务架构
大多数业务数据是作为一系列事件或事件流生成的：例如，Web或移动应用程序交互，传感器数据，银行交易和医疗设备。 微服务通常具有事件驱动架构，使用仅附加事件流，例如Kafka或MapR事件流（提供Kafka API）。
使用MapR-ES（或Kafka），事件被分组为称为“topics”的事件的逻辑集合。 主题【topics】被分区并行处理。
与队列不同，事件在传递后不会被删除，而是保留在分区上，可供其它消费者使用。
基于流的有效时间设置，旧的消息会被删除。如果设置为0，则永远不会被删除。
在读取时，消息不会从主题中删除，并且主题可以具有多个不同的消费者；这允许不同的消费者针对不同的目的处理相同的消息。Pipelining 也是可能的，其中消费者将event 发布到另一个主题。
MAPR ES提供可扩展的高性能消息传递，在普通硬件上每秒发送数百万条消息。发布/订阅kafka API提供解耦的通信，使得在不破坏现有进程的情况下很容易添加新的listeners 或新publishers 。
当将这些消息传递能力与微服务相结合时，可以极大地增强构建、部署和维护复杂数据管道的灵活性。通过简单地链接多个微服务来构建流水线，每个微服务监听某些数据的到达，执行指定的任务，并且可选地将其自己的消息发布到一个主题。
流是记录系统
事件源是一种体系结构模式，其中应用程序的状态由一系列事件决定，每个事件都记录在仅追加事件存储或则流中。 例如，假设每个“事件”是对数据库中条目的增量更新。 在这种情况下，特定条目的状态仅仅是与该条目有关的事件的累积。在下面的示例中，流保存所有存款和取款事件的队列，数据库表保存当前帐户余额。
流或数据库，哪一个是更好的记录系统？流中的事件可以用来重建数据库中的账户余额，而数据库却不能反过。
微服务添加到单片银行应用程序
银行通常有大型机应用程序，这些应用程序运行成本高，难于更新，也难于完全替换。让我们来看看如何将事件驱动的微服务添加到一个整体银行应用程序中，该应用程序包括支付事务和批处理作业，用于欺诈检测、报表和促销邮件。
在如下所示的设计中，来自单片数据库提交日志的支付事务被发布到流中，流被设置为永不丢弃数据。不变事件存储(流)成为记录系统，事件由不同的数据管道根据用例处理。事件数据管道通向多种语言持久性、不同的数据存储技术，每一种技术都提供不同的物化视图:MapR-DB HBase和MapR-DB JSON文档、图形和搜索数据库，因此，微服务总是以最合适的格式显示其数据的最新视图。使用命令查询责任分离模式。
事件存储通过在流中重新运行事件来提供重建状态——这是事件来源模式。事件可以重新处理，以创建新的索引、缓存或数据视图。
consumer简单的读取从最旧的消息到最新的创建一个数据视图
现在支付交易来自实时，使用Spark Machine Learning和Streaming进行实时欺诈检测可能比以前更容易，如数据流所示：
对于流中的事件具有较长的保留时间允许更多的分析和功能被添加。
通过添加事件和微服务来开发体系结构
随着更多的事件源，可以添加流处理和机器学习以提供新的功能。跨范围的交互（包括点击流、点击率、呼叫中心报告、客户偏好和购买数据）的机器学习技术可以用来提供见解，例如：财务建议、预测、警报和相关优惠。例如，可以将Web点击流分析与购买历史相结合，将共享行为亲和力的客户分组，以便更好地针对广告。当客户点击目标提供，触发MAPR DB中的客户配置文件更新，并向前景自动运动时，可以将领先事件添加到流中。
医疗保健实例
现在让我们来看看如何实现流优先架构。 来自某医院，供应商和实验室的数据。 MapR-ES解决了HIPAA合规性的数据沿袭问题，因为流成为每个数据变化的无限，不可变日志的记录系统。 多语言持久性解决了存储多种数据格式的问题。 可以为不同的用例提供，探索和分析MapR-DB HBase API / MapR-DB JSON API，图形和搜索数据库，物化视图。
零售示例
一家大型零售商希望提高季节敏捷性和库存纪律，以便对需求变化作出反应并减少降价。
数据收集自销售交易、库存状况和定价、竞争情报、社交媒体、天气和客户(去掉个人身份识别)，以便集中分析与改善业务相关的相关性和模式。大数据算法分析店内和在线购物、Twitter趋势、本地体育赛事和天气购买模式，构建个性化客户体验的创新应用程序，同时提高物流效率。销售点交易被分析以提供产品推荐或折扣，基于哪些产品是一起购买的，或者是在其他产品之前。预测分析是用来知道在某些特定的日子里，哪些产品在某些特定的商店里卖得更多，以减少库存过剩，并保持对最需要的产品的适当储备，从而帮助优化供应链。
结论
几个不同的技术转移的融合极大地改变了应用程序的构建方式。事件驱动的微服务、容器、Kubernetes和机器学习数据管道的结合正在加速下一代智能应用的发展，这些应用正在利用现代计算基础设施所驱动的现代计算范例。MAPR融合数据平台集成了全球事件流、实时数据库能力和可扩展的企业存储，以及数据处理和分析引擎的集合，为新一代的数据处理流水线和智能应用提供动力。
转载注明来自about云
本文链接
http://www.aboutyun.com/forum.php?mod=viewthread&tid=24783
感谢分享 借鉴下观念， 不错~~~
页:
[1]