服务设计

　　微服务是一宗分布式系统解决方案，推动细粒度服务的试用，这些服务协同工作，且每个服务都有自己的生命周期。因为微服务主要围绕业务领域建模，所以避免了有传统的分层架构引发的很多问题。 1、微服务 背景 　　随着领域驱动设计，持续交付，按需虚拟化，基础设施自动化，小型自制团队，大型集群系统这些实践的流行，微服务孕育而生 定义 　　微服务就是一些协同工作的小而自制的服务 特点 很小，专注做一件事情 内聚性：把因相同原因而变化的东西聚合在一起，把因不同原因而变化的东西分离出来 边界划分原则：在一两个周内完全可以重写 产生的问题：太小则独立性强，但管理大量的服务就越负责 　　自治性 尽量避免把多个服务部署到同一个服务器上 服务之间通过网络调用进行通讯，从而避免了服务之间的耦合，加强了隔离性 优点 　　技术异构性，弹性，扩展，简化部署，与组织结构相匹配，可组合性，对可替代性的优化 SOA 　　定义： SOA （ Service-Oriented Architecure, 面向服务的架构）是一种设计方法，其中包含多个服务，而服务之间通过配合最终会提供一系列功能。 　　与微服务的差别：一个服务通常以独立的形式存在于操作系统进程中。服务之间通过网络调用，而非采用进程内调用的方式进行。 　　问题：通信协议（如 SOAP ）选择，第三方中间件选择，服务颗粒如何确定 　　 其他分解技术 　　　　共享库 ,

微服务基本概念 专注做好一件事。一方面服务的大小是相对的，而且服务越小，服务数量越多，管理起来就越复杂，这也需要利弊权衡。 自治性。即服务通过暴露API，服务间通过API通信，解耦合。 微服务的好处 微服务的好处主要是针对传统的大型复杂服务而言 技术异构性。每个服务可以选用自己的技术，尝试自己需要的，或者新的技术，而不影响其他服务 弹性。服务之间有边界，即一个服务有问题不会影响其他功能，或者其他服务负责的功能。 扩展。如过一个服务有性能问题需要扩展，那么不需要同时扩展其他服务。 简化部署。一个服务的代码修改，不需要部署其他服务。 与组织结构相匹配。各个团队可以负责自己的N个服务，而不用管其他团队的服务。 可组合性。因为通过API进行服务通信，所以其他模块都可通过API对接某个服务 问题：没有银弹。多服务管理复杂，部署、测试、监控等方面都需要额外的开销。 如何建模微服务 　　 主要讲了什么时候划分出微服务，总结是，先内部分模块解决，再等界限清晰，最后划分微服务 　　模块和服务，不要过早使用微服务：微服务是目标做到、而且容易做到 高内聚低耦合的，当我们通过逻辑或者功能来划分时，比如一个进程内，可以优先考虑多模块划分，这也是一种减少耦合的方式。而这些模块的划分，也是以后划分微服务的最好备选。 所以一个新系统，如果界限不是特别清晰，可以先考虑做模块划分

　　大多数设计学科都来自于其他领域。 科技、认知科学和美学都对我们今天所知的设计做出了贡献。 服务设计，一个最近的设计专业应用，也没有什么不同。 其借鉴了许多概念，从用户体验、市场营销和项目管理，到优化新服务。 　　 　　服务设计最初是在1991年时，在kln国际设计学院引入的设计学科。 作为一个新领域，服务设计的定义在学术界不断发展。 　　 但在实践中，服务设计是： 为提高服务质量和服务提供者与客户之间的交互，规划和组织人员、基础设施、通信和材料组件的活动。 服务设计方法的目的是根据客户或参与者的需求进行设计，使服务具有用户友好性、竞争力和与客户的相关性。（ 服务设计网络） 　　五个基本原则 　　服务设计的概念如何转化为实践？ 区分服务设计和用户体验的元素是什么？ 这是最早的关于服务设计的要求之一。也是Marc Stickdorn和Jakob Schneider的服务设计思想，它概述了在重新思考服务时要记住的五个关键原则： 　　1）以用户为中心：人们处于服务设计的中心。 　　2）协同创新：服务设计应该包括其他人，特别是那些属于系统或服务的人。 　　3）排序：服务应该通过序列，或者客户旅程中的关键时刻来可视化。 　　4）证明：客户需要了解服务的元素。 证明能创造忠诚，帮助客户了解整个服务体验。 　　5）整体设计：整体设计考虑到服务的整个体验。 环境很重要。 　　标记工具 　

为什么说云原生会成为未来企业技术变迁的趋势 云原生是当下的热点话题，但是很多人对云原生有很多误解，特别是传统产业物联网或工控、物联网行业对云原生显得"后知后觉"。与其在这里说是预测，不如说是现在进行时，只是由于传统产业本身的技术包袱和组织个人认识程度差异，目前发展并不见快。目前大部分的系统还是停留在旧年代，只是不到火候，还没到尝鲜和推倒重来的必要。但是，面对未来业务的持续增长和行业竞争，必然要面临一个技术的现代化转型升级，即：使用新技术代替老技术，使用新观念代替老观念的痛苦过程。否则老系统必然会变成企业发展的一个瓶颈，因为基于老系统的修修补补只会使系统变得更加复杂和难以维护，最后等待他们的是要么推到重来，要么是逐年生锈老化（修修补补又三年）。我这里针对新近的云原生作为一个切入点，来说明一下为什么说云原生会成为未来企业技术变迁的一个趋势。 概念诞生 　　云原生（Cloud Native）的概念，由来自Pivotal的MattStine于2013年首次提出，被一直延续使用至今。 　　这个概念是Matt Stine根据其多年的架构和咨询经验总结出来的一个思想集合，并得到了社区的不断完善，内容非常多，包括： DevOps 持续交付（Continuous Delivery） 微服务（MicroServices） 敏捷基础设施（Agile Infrastructure）和12要素（The

1、如果A-B-C强相关 考虑采用TCC框架 ByteTCC，Himly 阿里的fescar，seata 推荐使用seata TCC框架 2、如果A 与BC并不强相关 考虑可靠消息最终一致性解决方案，例如A成功后通过发送kafka事件，BC监听事件来处理。 rocketMQ，提供了分布式事务支持。 来源： CSDN 作者： 雪落南城 链接： https://blog.csdn.net/lbh199466/article/details/104641811

版权声明：本文由韩伟原创文章，转载请注明出处: 文章原文链接： https://www.qcloud.com/community/article/162 来源：腾云阁 https://www.qcloud.com/community RPC是一种方便的网络通信编程模型，由于和编程语言的高度结合，大大减少了处理网络数据的复杂度，让代码可读性也有可观的提高。但是RPC本身的构成却比较复杂，由于受到编程语言、网络模型、使用习惯的约束，有大量的妥协和取舍之处。本文就是通过分析几种流行的RPC实现案例，提供大家在设计RPC系统时的参考。 由于RPC底层的网络开发一般和具体使用环境有关，而编程实现手段也非常多样化，但不影响使用者，因此本文基本涉及如何实现一个RPC系统。 认识RPC（远程调用） 我们在各种操作系统、编程语言生态圈中，多少都会接触过“远程调用”的概念。一般来说，他们指的是用简单的一行代码，通过网络调用另外一个计算机上的某段程序。比如： RMI——Remote Method Invoke：调用远程的方法。“方法”一般是附属于某个对象上的，所以通常RMI指对在远程的计算机上的某个对象，进行其方法函数的调用。 RPC——Remote Procedure Call：远程过程调用。指的是对网络上另外一个计算机上的，某段特定的函数代码的调用。 远程调用本身是网络通信的一种概念

定时任务,在很多业务场景中都会存在.一般,我们简单解决的话,就是使用数据库来存储数据供服务端周期获取执行.显然,对于数据库处理,如果多线程或者多机器处理,就会存在扩展的问题.比如:现在一个任务记录到时间了需要执行,同时被多个executor抓取来执行,就会浪费不必要的资源;并且,这种场景还非常常见. 因此, 需要额外状态处理,或者其他分库分表策略保证尽量一个executor来操作一个记录,并且如果executor失败了,其他的executor才会去执行分配给失败executor的任务. 整个设计相对而言,就相当复杂了. 基于上面的一些原因,这里我们设计了一个简单的基于kafka消息队列的定时任务方案. 这里，首先定义一下定时消息。所谓定时消息，就是业务方根据自己的业务需求，指定在接下来的大概某个时间点来发送某条消息，从而保证该消息在某个时间点之后可接受的时间区间内消费该消息。所以这里需要指出： Note: 消息机制都是异步的，所以如果存在大量消息累积未消费，则无法保证定时消息指定的时间区间。因此，使用的时候，必须预计定时消息服务提供的服务能否满足业务的QPS要求。定时消息服务设计保证支持水平扩展，因此，可以根据业务性能需求，部署足够的服务。 kafka消息队列，所有触发都是基于消息机制的。所以，定时任务的设计必须要有定时消息服务来提供基础核心功能。首先

在微服务架构中，需要调用很多服务才能完成一项功能。服务之间如何互相调用就变成微服务架构中的一个关键问题。 服务调用有两种方式，一种是RPC方式，另一种是事件驱动（Event-driven）方式，也就是发消息方式。 消息方式是松耦合方式，比紧耦合的RPC方式要优越，但RPC方式如果用在适合的场景也有它的一席之地。 我们总在谈耦合，那么耦合到底意味着什么呢？ 耦合的种类： 时间耦合： 客户端和服务端必须同时上线才能工作。发消息时，接受消息队列必须运行，但后台处理程序暂时不工作也不影响。 容量耦合： 客户端和服务端的处理容量必须匹配。发消息时，如果后台处理能力不足也不要紧，消息队列会起到缓冲的作用。 接口耦合： RPC调用有函数标签，而消息队列只是一个消息。例如买了商品之后要调用发货服务，如果是发消息，那么就只需发送一个商品被买消息。 发送方式耦合： RPC是点对点方式，需要知道对方是谁，它的好处是能够传回返回值。消息既可以点对点，也可以用广播的方式，这样减少了耦合，但也使返回值比较困难。 下面我们来逐一分析这些耦合的影响。第一，时间耦合，对于多数应用来讲，你希望能马上得到回答，因此即使使用消息队列，后台也需要一直工作。 第二，容量耦合，如果你对回复有时间要求，那么消息队列的缓冲功能作用不大，因为你希望及时响应。 真正需要的是自动伸缩（Auto-scaling）

此文已由作者刘超授权网易云社区发布。 欢迎访问 网易云社区 ，了解更多网易技术产品运营经验。 十、基于Hadoop和Spark了解大数据平台 对于数据架构的部分，其实经历了三个过程，分别是Hadoop Map-Reduce 1.0，基于Yarn的Map-Reduce 2.0, 还有Spark。 如下图是Map-Reduce 1.0的过程。 Map-Reduce的过程将一个大任务，split称为多个Map Task，分散到多台机器并行处理，将处理的结果保存到本地，第二个阶段，Reduce Task将中间结果拷贝过来，将结果集中处理，取得最终结果。 在Map-Reduce 1.0的时候，跑任务的方式只有这一种，为了应对复杂的场景，将任务的调度和资源的调度分成两层。其中资源的调用由Yarn进行，Yarn不管是Map还是Reduce，只要向他请求，他就找到空闲的资源分配给他。 每个任务启动的时候，专门启动一个Application Master，管理任务的调度，他是知道Map和Reduce的。这就是Map-Reduce 2.0如下图。 这里Yarn相当于外包公司的老板，所有的员工都是worker，都是他的资源，外包公司的老板是不清楚接的每一个项目的。 Application Master相当于接的每个项目的项目经理，他是知道项目的具体情况的，他在执行项目的时候，如果需要员工干活

本文由 网易云 发布。 作者：刘超，网易云首席解决方案架构师 最近总在思考，为什么在支撑容器平台和微服务的竞争中，Kubernetes 会取得最终的胜出，事实上从很多角度出发三大容器平台从功能方面来看，最后简直是一摸一样。（可参考 《容器平台选型的十大模式：Docker、DC/OS、K8S 谁与当先？》 ） 经过一段时间的思索，以及采访了从早期就开始实践 Kubernetes 的 网易云 架构师们后，我把反思所得总结为今天的这篇文章。 一、从企业上云的三大架构看容器平台的三种视角 如图所示，企业上云的三大架构为 IT 架构、应用架构和数据架构，在不同的公司，不同的人、不同的角色，关注的重点不同。 对大部分的企业来讲，上云的诉求是从 IT 部门发起的，发起人往往是运维部门，他们关注计算、网络、存储，试图通过云计算服务来减轻 CAPEX 和 OPEX。 有的公司有 ToC 的业务，因而累积了大量的用户数据，公司的运营需要通过这部分数据进行大数据分析和数字化运营，因而在这些企业里面往往还需要关注数据架构。 从事互联网应用的企业，往往首先关注的是应用架构，是否能够满足终端客户的需求，带给客户良好的用户体验。业务量上往往会有短期内出现爆炸式增长的现象，因而关注高并发应用架构，并希望这个架构可以快速迭代，从而抢占风口。 在容器出现之前，这三种架构往往通过虚拟机云平台的方式解决。当容器出现之后