服务化与微服务

=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

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

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

发表评论

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