微服务架构学习与思考(01)：什么是微服务？微服务的优势和劣势

微服务架构学习系列文章：

一、单体应用

在软件开发早期阶段，大家都在一个应用系统上开发。各个业务模块之间耦合也比较紧密。软件发布也是整体发布，或者对软件进行打包发布和部署，比如java可以打包成war部署。测试也很容易，因为代码都在一起，基本不需要引用外部的关联服务。

在软件开发早期，这种软件开发模式能适应业务的发展，软件应用也可以正常运行。

如果你的业务发展良好，客户需求会变得越来越多，软件功能数也会随着客户的需求变多而变多。为了实现这些功能，你必须添加很多代码。而随着业务进一步发展，代码量势必也会越增越多。有可能 2 到 3年后，软件代码量会变得非常巨大。那时软件就会变成一个非常庞大且复杂的单体应用。软件里面的功能多，代码错综复杂。类似下面这种布线图：

此时可能出现的问题：

  1. 打包编译会耗时很久，导致发布也很耗时。
  2. 代码可维护性变差，因为代码量大，逻辑复杂，只有少数老员工能全部理解。代码腐化严重。
  3. 修改bug和增加新功能会变得困难，可能牵一发而动全身。
  4. 由于上面的原因，软件扩展变得困难
  5. 软件可用性风险增加。可能一个bug导致整个软件不可用。

为了解决上面的这些问题，怎么办？ 俗话说：“大事化小”，一个字，拆！ 希望系统能逐渐进入有序状态，像下面这样：

二、应用拆分

第一步可能想到的就是拆分应用。

把一个像“大泥球 ”一样的单体应用可以按照业务功能进行拆分。比如电商应用，可能拆分为商品应用，订单应用，用户应用，商铺应用等等相对比较小的应用功能。

业务规模进一步发展，你可能把上面的应用做进一步拆分，变成更小的应用，以服务的形式对外提供应用服务。应用慢慢的拆分为了比较小的服务 - 微服务。

随着软件架构的调整，能解决上面遇到的所有问题吗？大部分可以解决。
服务稳定的运行了一段时间，你也过了一段舒服的日子。但是在使用微服务的过程中，问题也逐渐暴露出来，微服务会带来什么问题呢？下面对微服务进行一些思考。

三、微服务思考

什么是微服务

维基百科定义：

微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信。

AWS 的定义：

微服务是一种开发软件的架构和组织方法，其中软件由通过明确定义的API 进行通信的小型独立服务组成。 这些服务由各个小型独立团队负责。 微服务架构使应用程序更易于扩展和更快地开发，从而加速创新并缩短新功能的上市时间

thoughtworks 首席科学家 马丁.福勒（Martin Fowler）的定义：

微服务架构是一种架构模式，它提倡将单一应用程序划分为一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立进程中，服务与服务之间通常采用轻量级的通信机制相互沟通。每个服务都围绕具体的业务进行构建，并且能独立部署到生产环境中。

微服务有哪些优势与劣势（问题）

  • 优势：
  1. 应用小，可快速编译部署
  2. 单个微服务维护性变高，修改容易，因为每个团队独立负责一块功能。新功能交付变快，可以快速开发交付
  3. 扩展性变高，根据业务规模可以随时缩减/增加服务器规模
  4. 可靠性变强，可以部署很多独立的服务
  5. 业务解耦，按照业务边界拆分为多个独立的服务模块
  6. 提升研发效率，业务拆分后，服务模块变小，在一个团队内就可以独立编写、测试、发布，加快研发效率。

拆分后，单个微服务比较小，它只专注于做好一件事情。
拆分的指导原则：高内聚，低耦合。

单一微服务有点像软件设计中的单一职责原则：

Martin 对单一职责有一个论述：
把因相同原因而变化的东西聚合到一起，而把因不同原因而变化的东西分离开来。

这个论述也强调了内聚性。

微服务有这么多优势，那微服务是“银弹”吗？微服务不是银弹，它带来了很多优势，同时也带来了很多劣势（问题）。

  • 劣势（问题）：
  1. 整体复杂度变高，从哪些方面来管理这种复杂度？
  2. 运维变得复杂：微服务变多，怎么监控所有微服务，保证服务稳定？出了问题，怎么定位问题？
  3. 服务管理：微服务变多，管理复杂度变高，治理变得复杂
  4. 测试方面的挑战：你需要结合其他的微服务来进行集成测试
  5. 分布式问题：分布式数据一致性、分布式事务
  6. 服务可用性保障：一个服务出了问题，如何才能不影响其他服务？

根据上面微服务定义，这些服务都是由小型独立团队负责，那团队怎么划分？公司组织架构如何调整才能适应微服务的架构发展？这也给组织管理带来了变革的挑战。

还有微服务的“微”，多“微”才是好的“微”？也就是微服务怎么划分，如何确定边界？
等等这些都是微服务面临的问题和挑战。

题外话：任何问题都有正反面，就像一枚硬币一样，所以思考问题要多样化，不能只思考一点。

四、总结

根据以上简略分析，微服务的实施并不是一蹴而就的事情，是随着业务的发展而发展，是一种逐渐演进的架构模式。

微服务架构是为了适应业务的快速变化，产品的快速迭代、交付、反馈和修改，团队成员膨胀而提出的一种架构解决方案。

微服务的优劣分析可以看出，微服务并不是“银弹”，它给开发和产品带来好处的同时，本身也会带来一系列的问题。如何克服这些问题，才是实施好微服务的关键所在。

上面提到的劣势（问题），也需要建立运维开发基础设施来加以保障才能让微服务顺利运行。比如CI/CD，监控体系，配置中心等等，那DevOps是否也要同步建设？

所以成功实施微服务并不是一件孤立的事情，它关联很多其他事情，架构、工具到团队协同，需要同步建设，它是一个系统工程。

也可以到公号讨论 什么是微服务？微服务的优势和劣势

posted @ 2020-07-10 17:43  九卷  阅读(3795)  评论(2)  编辑  收藏  举报