服务化与微服务

本文最后更新于2018年3月16日,已超过 1 年没有更新,如果文章内容失效,还请反馈给我,谢谢!

=Start=

缘由:

整理一些在微信公众号、博客里看到的和「服务化」与「微服务」相关的文章、资料,方便学习和参考。

正文:

参考解答:
为什么要进行服务化?

随着数据量、并发量、业务复杂度的增长,互联网架构会出现以下问题:

  1. 代码到处拷贝
  2. 底层复杂性扩散
  3. 基础库(so/jar/dll)耦合
  4. SQL质量得不到保障,业务相互影响
  5. 数据库耦合

“服务化”是一个很好的解决上述痛点的方案。但是服务化之后,随着规模的扩大,一定要考虑“服务治理”,否则服务之间的依赖关系会乱成麻。


不同粒度的服务化各有什么优劣?

总的来说,细粒度拆分的优点有:

  1. 服务都能够独立部署
  2. 扩容和缩容方便,有利于提高资源利用率
  3. 拆得越细,耦合相对会减小
  4. 拆得越细,容错相对会更好,一个服务出问题不影响其他服务
  5. 扩展性更好

细粒度拆分的不足也很明显:

  1. 拆得越细,系统越复杂
  2. 系统之间的依赖关系也更复杂
  3. 运维复杂度提升
  4. 监控更加复杂
  5. 出问题时定位问题更难

关于微服务架构的“粒度”问题,需要根据各自业务、场景的实际情况进行选取,并没有一种万能的方案可以cover住所有场景。

参考链接:

=END=

声明: 除非注明,ixyzero.com文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://ixyzero.com/blog/archives/3825.html

《服务化与微服务》上有28条评论

  1. 从 Spring Cloud 看一个微服务框架的「五脏六腑」
    http://www.importnew.com/28514.html

    Spring Cloud 是一个基于 Spring Boot 实现的微服务框架,它包含了实现微服务架构所需的各种组件。

    面向服务的架构(SOA)和微服务架构是目前两种主流的服务化架构。准确地说微服务是去 ESB(企业服务总线)的 SOA。ESB 借鉴了计算机组成原理中的通信模型 —— 总线,所有需要和外部系统通信的系统,通过 ESB 进行标准化地转换从而消除协议、异构系统之间的差异,这样就可以利用现有的系统构建一个全新的松耦合的异构的分布式系统。微服务架构去掉 ESB,本质上是一种去中心化的思想。

    服务在哪?(服务治理问题)
    怎么调用?(服务调用问题)

    服务治理为心脏,路由网关、消息中心、断路器、链路追踪、配置中心等为依托,构造了整个微服务框架的「五脏六腑」。当然,一个微服务系统远比本文所写的复杂得多,尤其是在不同的业务场景之下,因此想要更深入地了解它就需要我们不断地去实践。而作为前端,我了解这些内容一是为了更好地了解整个请求的流程,二是为了后续在 SOA 中接入 Node 子服务积累相关知识。

    最后分享一句有趣的调侃 Spring 的话:在 Spring 中没有什么是一个注解解决不了的,如果有,那么就用两个注解。

  2. 微服务化的基石——持续集成
    https://mp.weixin.qq.com/s/PDrzITSgkDgvnm01APOixQ

    一、持续集成对于微服务的意义:拆之前要先解决合的问题
    从一个简单的单体应用,变成如此复杂的微服务架构,除了关心怎么拆的问题,还必须关注:
      如何控制拆的风险
      如何保证代码质量
      如何保证功能不变,不引入新的Bug

    答案当然就是集成,从一开始就集成,并且不断的集成,反复的将拆分的模块重新组合,看看是否能够顺利组合起来,并且保证功能的不变。

    要是不没事儿就组合一下,天知道几个月以后还能不能合的起来。

    二、持续集成就是不断的尝试在一起
    为什么需要一个统一的代码仓库Git来做代码管理呢?是为了代码集成在一起。
    为什么需要进行构建build呢?就是代码逻辑需要集成在一起,编译不出错
    为什么要单元测试呢?一个模块的功能集成在一起能够正确工作。
    为什么需要联调测试Staging环境呢?需要将不同模块之间集成在一起,在一个类生产的环境中进行测试。
    最终才是部署到生产环境中,将所有人分开做的工作才算真正的合在了一起。

    三、持续集成,持续交付,持续部署,敏捷开发,DevOps都啥关系?
    持续集成往往指对代码的提交,构建,测试的过程,也就是上述的在一起的过程。
    持续交付是指将集成好的交付物,例如war,jar,或者容器镜像,部署在联调环境,或者预发环境的过程。
    持续部署是指将交付物持续部署在生产环境的过程。

    四、从一个持续集成的日常,看上述的几个概念如何实践

    五、有关代码结构

    六、有关接口设计规范

    七、有关代码设计

    八、有关配置文件

    九、有关数据库版本

  3. 微服务架构实践(日志收集)
    https://mp.weixin.qq.com/s/9AdvXP7gEuCvuR70DYW43w

    任何复杂的应用程序偶尔都会出现错误。在微服务应用程序中,需要跟踪几十甚至几百个服务发生的情况。要获取系统的整体视图,日志记录和监控至关重要。在微服务架构中,一个业务请求会经历多个服务,收集端到端链路上的日志能够帮助我们判断错误发生的具体位置。

  4. 微服务的10个挑战和解决方案
    http://mushiming.top/mushblog/archives/823
    https://dzone.com/articles/10-challenges-of-microservices-and-solutions-tips

    1.数据同步 – 我们使用事件源代码架构来使用异步消息传递平台解决此问题。传奇设计模式可以应对这一挑战。

    2.安全性 – API网关可以解决这些挑战。Kong非常受欢迎,并且是开源的,并且正在被许多公司用于生产。还可以使用JWT令牌,Spring Security和Netflix Zuul / Zuul2为API安全性开发自定义解决方案。还有企业解决方案,如Apigee和Okta(两步认证)。Openshift用于公共云安全的顶级功能,如基于Red Hat Linux Kernel的安全性和基于命名空间的app-to-app安全性。

    3.版本控制 – 这将由API注册表和发现API使用动态Swagger API处理,动态Swagger API可以动态更新并与服务器上的使用者共享。

    4. 发现 – 这将由Kubernetes和OpenShift等API发现工具解决。它也可以在代码级使用Netflix Eureka完成。但是,使用业务流程层执行此操作会更好,并且可以通过这些工具进行管理,而不是通过代码和配置进行维护。

    5.数据过期 – 应始终更新数据库以提供最新数据。API将从最近更新的数据库中获取数据。还可以为数据库中的每个记录添加时间戳条目,以检查和验证最近的数据。可以根据业务需求使用可定义的驱逐策略来使用和自定义缓存。

    6.调试和记录 – 有多种解决方案。可以通过将日志消息推送到异步消息传递平台(如Kafka,Google PubSub等)来使用外化日志记录。客户端可以在标头中为REST API提供关联ID,以跟踪所有pod / Docker容器中的相关日志。此外,可以使用IDE或检查日志在每个微服务上单独完成本地调试。

    7.测试 – 可以通过模拟REST API或集成/依赖API来解决此问题,这些API不可用于使用WireMock,BDD,Cucumber,集成测试,使用JMeter进行性能测试以及任何良好的分析工具(如Jprofiler)进行测试, DynaTrace,YourToolKit,VisualVM等

    8.监控 – 监控可以使用开源工具,如Prometheus与Grafana结合使用,创建仪表和矩阵,Kubernetes / OpensShift,Influx DB,Apigee,结合Grafana和Graphite。

    9. DevOps支持 – 使用最先进的DevOps工具(如GCP,Kubernetes和OpenShift与Jenkins)可以解决微服务部署和支持相关的挑战。

    10.容错 – 如果给定SLA / ETA的API没有响应,Netflix Hystrix可用于断开电路。

  5. 程序员练级攻略(2018):微服务
    https://time.geekbang.org/column/article/11116

    微服务是分布式系统中最近比较流行的架构模型,也是 SOA 架构的一个进化。微服务架构并不是银弹,所以,也不要寄希望于微服务构架能够解决所有的问题。微服务架构主要解决的是如何快速地开发和部署我们的服务,这对于一个能够适应快速开发和成长的公司是非常必要的。同时我也觉得,微服务中有很多很不错的想法和理念,所以学习微服务是每一个技术人员迈向卓越的架构师的必经之路。

    首先,你需要看一下,Martin Fowler 的这篇关于微服务架构的文档:
    Microservice Architecture
    http://martinfowler.com/articles/microservices.html
    https://blog.csdn.net/wurenhai/article/details/37659335 #中译版
    这篇文章说明了微服务的架构与传统架构的不同之处在于,微服务的每个服务与其数据库都是独立的,可以无依赖地进行部署。你也可以看看 Martin Fowler 老人家现身说法的视频。

    另外,你还可以简单地浏览一下,各家对微服务的理解。
    AWS 的理解 – What are Microservices?
    https://aws.amazon.com/microservices/

    Microsoft 的理解 – Microservices architecture style
    https://docs.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices

    Pivotal 的理解 – Microservices
    https://pivotal.io/microservices

  6. 讨论微服务之前,你知道微服务的 4 个定义吗?
    https://wizardbyron.github.io/2018/09/14/2018-09-14-four-definitions-of-microservices/

    关于“什么是微服务”的问题,其实并没有一个统一的认识。这些年在不同的场合里和不同背景的朋友都在探讨微服务。但聊得越多,就越发现大家聊的不是同一回事。和 DevOps 一样,“微服务”也是一个内涵十分广泛的词。本文从“Microservice“这个概念的源头出发,总结了 4 个常用的微服务定义。

    本文总结了微服务常见的 4 个定义。但比这些定义更重要的是你为什么要用微服务?你想从微服务中获得什么益处?你是否了解为了追求这些益处所带来的代价?如果不先明确这些问题,在不理解微服务架构或者技术所带来的的风险和成本。盲目的采用所谓的微服务,可能带来的结果并不理想。

  7. 聊聊分布式链路追踪
    http://lidawn.github.io/2018/12/26/distribute-tracing/

    1. 起因
    2. 什么是链路追踪
    3. Dapper
    3.1. Trace、Span、Annotations
    3.2. 带内数据与带外数据
    3.3. 采样
    3.4. 存储
    4. Zipkin
    4.1. 架构
    4.2. 数据模型
    4.2.1. Span
    4.2.2. 带内数据与采样机制
    4.3. 数据埋点及上报过程
    5. Open-Tracing
    6. 参考

  8. 天机阁——全链路跟踪系统设计与实现
    https://mp.weixin.qq.com/s/RBPJFrj2mcTUjbm4aH9TRg

    为了支撑日益增长的庞大业务量,业界大量使用微服务架构。服务按照不同的维度进行拆分,互联网应用构建在不同的软件模块集上,这些软件模块可能是由不同的团队开发、可能使用不同的编程语言来实现、可能布在了几千台服务器,横跨多个不同的数据中心,分布式系统变得日趋复杂。

    如何快速进行故障定位?如何准确进行容量评估?如何动态展示服务的链路?如何进行系统性能优化?这是分布式系统给后台开发同学带来的四大挑战。业界都是通过链路跟踪系统来解决以上问题,然而腾讯在链路跟踪方面比较欠缺。为了填补此空白,“天机阁”系统横空出世。

    “天机阁”通过采集、存储、分析分布式系统中的trace数据、指标数据和日志数据,完成全链路跟踪,从而解决上述问题。目前天机阁接入了1200+个服务,trace数据上报峰值500万/分钟,指标数据上报峰值1.3亿/分钟,日志数据每天30T。如此海量的数据天机阁是怎样处理的?天机阁的链路跟踪是怎样实现的?又是怎样做到低侵入,低开销的?这些问题本文将一一为您揭秘。

    1. 分布式链路追踪系统的理论知识由Google在2010年《dapper》论文中发表,随后twitter开发出了一个开源版本zipkin;阿里内部开发了一套鹰眼系统;京东,唯品会等各个公司均有相关的组件。
      Google Dapper: 分布式链路追踪系统架构
      https://ai.google/research/pubs/pub36356

      Twitter Zipkin
      https://github.com/openzipkin/zipkin
      PinPoint
      https://github.com/naver/pinpoint
      SkyWalking
      http://beckjin.com/2018/09/09/skywalking/
      阿里鹰眼
      http://jm.taobao.org/2014/03/04/3465/
      https://cn.aliyun.com/aliware/news/monitoringsolution
      点评Cat
      https://github.com/dianping/cat

  9. 小团队的微服务之路
    https://deanwangpro.com/2019/02/18/road-of-microservice/

    1. 单体应用时代
    1.1. 接口定义
    1.2. 持续集成(CI)
    2. 微服务时代
    2.1. 服务拆分原则
    2.2. 框架选择
    2.3. 架构改造
    2.4. 自动化部署
    2.5. 链路跟踪
    2.6. 运维监控
    3. 容器化时代
    3.1. 架构改造
    3.2. Spring Cloud与k8s的融合
    3.3. CI的改造
    4. 小结

  10. 微服务化后缓存怎么做
    https://paper.tuisec.win/detail/c0932e3ebc09c6c
    https://toutiao.io/posts/7q0a3u/preview
    https://martin.kleppmann.com/2012/10/01/rethinking-caching-in-web-apps.html

    缓存更新本身就是一个难解的问题,在微服务化后,多个服务就更加复杂了。涉及到跨服务的多级缓存一致性的问题。

    所以对大部分的业务,我们可以遵循这样的原则来简单有效处理。

    · 对数据的有效性比较敏感的调用都收敛到服务内部(领域内部应该更合适),不要暴露给调用方, 领域内部做数据的缓存失效控制

    · 缓存预计算(有些页面的地方不希望首次打开慢)的逻辑也应该放在领域内控制,不要暴露给调用方。 在领域内部控制在不同的地方使用不同的缓存策略,比如更新数据的地方需要获取及时的数据。比如商品的价格,和商品的所属类目更新频次不同,需要有不同的过期时间。

    · 跨服务调用为了减少rpc调用,可以再进行一层缓存。因为这些调用可以接受过期的数据,再进行一层缓存没问题,expired time叠加也没多大影响(expire time在这边主要是影响缓存的命中数)

    扩展:如果后续有case在跨服务的调用时,对数据的过期比较敏感,并且在调用方也做了缓存,那就是跨服务的多级缓存一致性的问题。那就需要服务方告知调用方缓存何时失效,使用消息队列or其他方式来实现。

  11. 从技术角度讨论微服务
    https://mp.weixin.qq.com/s/UukNe5i5WxzRN2rLYeL52Q

    本文希望从技术角度来探讨下微服务,因此,不会过多地谈及如何根据业务进行微服务划分,更多是介绍微服务的相关技术,微服务的业务划分方法可参考“领域驱动设计“相关方法论。

    微服务的两个程度
    一、服务化
    二、容器化

    服务注册发现
    一、最简单的服务注册发现
    二、基于中间件的服务注册发现
    三、基于容器治理平台的服务注册发现

    简单总结
      我认为,从架构的层面来看微服务架构,应该是这样的:
      扩展性:降低复杂系统的耦合度、沟通成本以及系统复杂度,需求快速响应;
      伸缩性:可以通过增加资源的方式来快速应对海量并发(仅仅是并发层面,大数据量还是需要根据业务进行分片或分割);
      稳定性:微服务治理平台,PaaS平台保证了系统的高可用性,可以降低业务的中断时间;
      安全性:和传统架构的要求差别不大,但是由于网关和网格(Service Mesh)的存在,使得安全处理,APM等的实现更加简单。

      另外,我认为微服务可以通过部署的方式来实现功能或模块的复用,一定程度上代替了过往通过jdk/sdk来实现共用的方式;使得开发更加灵活,也使得开发可以更加关注于业务,而非各种边边角角的公共(轮子)功能。

  12. 战术模式–领域事件
    http://www.geekhalo.com/2019/04/16/ddd/tactics/event/

    1 理解领域事件
    2 实现领域事件
    2.1 创建领域事件
    2.1.1 事件命名
    2.1.2 事件属性
    2.1.3 事件方法
    2.1.4 事件唯一标识
    2.2 发布领域事件
    2.2.1 发布订阅模型
    2.2.2 基于 ThreadLocal 的事件发布
    2.2.3 基于实体缓存的事件发布
    2.2.4 由调用方发布事件
    2.3 订阅领域事件
    2.4 处理领域事件
    2.4.1 保证聚合间的数据一致性
    2.4.2 替换批量处理
    2.4.3 实现事件源模式
    2.4.4 进行限界上下文集成
    2.5 异步处理领域事件
    2.6 内部事件与外部事件
    2.6.1 内部事件
    2.6.2 外部事件
    3 实现领域事件模式
    3.1 封装领域事件的“发布-订阅”模式
    3.2 内存总线处理内部事件,消息队列处理外部事件
    3.3 使用实体缓存领域事件
    3.4 使用 IOC 容器的事件发布功能

    4 小结
    领域事件是发生在问题域中的事实,它是通用语言的一部分。
    领域事件优先使用发布-订阅模式,会发布事件并且触发相应的事件处理器。
    限界上下文内,优先使用内部事件和内存总线;限界上下文间,优先使用外部事件和消息队列。
    领域事件使异步操作变得简单。
    领域事件为聚合间提供了最终一致性。
    领域事件可以将大的批量操作简化为许多小的业务操作。
    领域事件可以完成强大的事件存储。
    领域事件可以完成限界上下文间的集成。
    领域事件是更复杂架构(CQRS)的一种支持。

  13. 技术分享之service mesh (k8s&istio)的那些事儿
    http://xiaorui.cc/2019/08/24/%E6%8A%80%E6%9C%AF%E5%88%86%E4%BA%AB%E4%B9%8Bservice-mesh-k8sistio%E7%9A%84%E9%82%A3%E4%BA%9B%E4%BA%8B%E5%84%BF/

    这次分享的话题主要围绕微服务service mesh架构的实践,话题也是拆分了三个子topic,分别是微服务的演进史、kubernets、istio。本想做个简单偏科普的介绍,后来发现如单纯只是讲k8s、istio的介绍使用,而不去稍微讲点原理设计,可能会导致ppt的质量显得不高级,所以就又增加了不少原理性的介绍。

    https://github.com/rfyiamcool/share_ppt
    http://xiaorui.cc/static/service_mesh.pdf

发表评论

电子邮件地址不会被公开。 必填项已用*标注