第1次实践作业(1)课程调查

因为教务处没有本课程的授课计划和教学大纲,所以不知道这是一门什么样的课。根据课程名来看,大概是要对前几年学到的知识,来一次综合实践运用,提升我们的综合能力吧

(2)了解微服务

什么是微服务

根据维基百科上的定义,微服务是一种软件开发技术,是面向服务的架构(SOA)结构风格的一种变体,将应用程序编排成一系列松耦合的服务。在微服务架构中,各个服务是细粒度的,协议是轻量级的。

业务发展中的不合理情况

  • 网站和移动端应用有很多相同业务逻辑的重复代码。
  • 数据有时候通过数据库共享,有时候通过接口调用传输。接口调用关系杂乱。
  • 单个应用为了给其他应用提供接口,渐渐地越改越大,包含了很多本来就不属于它的逻辑。应用边界模糊,功能归属混乱。
  • 管理后台在一开始的设计中保障级别较低。加入数据分析和促销管理相关功能后出现性能瓶颈,影响了其他应用。
  • 数据库表结构被多个应用依赖,无法重构和优化。
  • 所有应用都在一个数据库上操作,数据库出现性能瓶颈。特别是数据分析跑起来的时候,数据库性能急剧下降。
  • 开发、测试、部署、维护愈发困难。即使只改动一个小功能,也需要整个应用一起发布。有时候发布会不小心带上了一些未经测试的代码,或者修改了一个功能后,另一个意想不到的地方出错了。为了减轻发布可能产生的问题的影响和线上业务停顿的影响,所有应用都要在凌晨三四点执行发布。发布后为了验证应用正常运行,还得盯到第二天白天的用户高峰期……
  • 团队出现推诿扯皮现象。关于一些公用的功能应该建设在哪个应用上的问题常常要争论很久,最后要么干脆各做各的,或者随便放个地方但是都不维护。

微服务优点

  • 提升开发交流,每个服务足够内聚,足够小,代码容易理解;
  • 服务独立测试、部署、升级、发布;
  • 按需定制的DFX,资源利用率,每

    因为教务处没有本课程的授课计划和教学大纲,所以不知道这是一门什么样的课。根据课程名来看,大概是要对前几年学到的知识,来一次综合实践运用,提升我们的综合能力吧

    (2)了解微服务

    什么是微服务

    根据维基百科上的定义,微服务是一种软件开发技术,是面向服务的架构(SOA)结构风格的一种变体,将应用程序编排成一系列松耦合的服务。在微服务架构中,各个服务是细粒度的,协议是轻量级的。

    业务发展中的不合理情况

    • 网站和移动端应用有很多相同业务逻辑的重复代码。
    • 数据有时候通过数据库共享,有时候通过接口调用传输。接口调用关系杂乱。
    • 单个应用为了给其他应用提供接口,渐渐地越改越大,包含了很多本来就不属于它的逻辑。应用边界模糊,功能归属混乱。
    • 管理后台在一开始的设计中保障级别较低。加入数据分析和促销管理相关功能后出现性能瓶颈,影响了其他应用。
    • 数据库表结构被多个应用依赖,无法重构和优化。
    • 所有应用都在一个数据库上操作,数据库出现性能瓶颈。特别是数据分析跑起来的时候,数据库性能急剧下降。
    • 开发、测试、部署、维护愈发困难。即使只改动一个小功能,也需要整个应用一起发布。有时候发布会不小心带上了一些未经测试的代码,或者修改了一个功能后,另一个意想不到的地方出错了。为了减轻发布可能产生的问题的影响和线上业务停顿的影响,所有应用都要在凌晨三四点执行发布。发布后为了验证应用正常运行,还得盯到第二天白天的用户高峰期……
    • 团队出现推诿扯皮现象。关于一些公用的功能应该建设在哪个应用上的问题常常要争论很久,最后要么干脆各做各的,或者随便放个地方但是都不维护。

    微服务优点

    • 提升开发交流,每个服务足够内聚,足够小,代码容易理解;
    • 服务独立测试、部署、升级、发布;
    • 按需定制的DFX,资源利用率,每个服务可以各自进行x扩展和z扩展,而且,每个服务可以根据自己的需要部署到合适的硬件服务器上;每个服务按
    • 需要选择HA的模式,选择接受服务的实例个数;
    • 容易扩大开发团队,可以针对每个服务(service)组件开发团队;
    • 提高容错性(fault isolation),一个服务的内存泄露并不会让整个系统瘫痪;
    • 新技术的应用,系统不会被长期限制在某个技术栈上;

    微服务缺点

    • 没有银弹,微服务提高了系统的复杂度;
    • 开发人员要处理分布式系统的复杂性;
    • 服务之间的分布式通信问题;
    • 服务的注册与发现问题;
    • 服务之间的分布式事务问题;
    • 数据隔离再来的报表处理问题;
    • 服务之间的分布式一致性问题;
    • 服务管理的复杂性,服务的编排;
    • 不同服务实例的管理。
    个服务可以各自进行x扩展和z扩展,而且,每个服务可以根据自己的需要部署到合适的硬件服务器上;每个服务按
  • 需要选择HA的模式,选择接受服务的实例个数;
  • 容易扩大开发团队,可以针对每个服务(service)组件开发团队;
  • 提高容错性(fault isolation),一个服务的内存泄露并不会让整个系统瘫痪;
  • 新技术的应用,系统不会被长期限制在某个技术栈上;

微服务缺点

  • 没有银弹,微服务提高了系统的复杂度;
  • 开发人员要处理分布式系统的复杂性;
  • 服务之间的分布式通信问题;
  • 服务的注册与发现问题;
  • 服务之间的分布式事务问题;
  • 数据隔离再来的报表处理问题;
  • 服务之间的分布式一致性问题;
  • 服务管理的复杂性,服务的编排;
  • 不同服务实例的管理。

猜你喜欢

转载自www.cnblogs.com/sy211910/p/12710028.html