服务化与微服务

=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

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

  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

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

发表评论

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