作者：shawn
前言
当前流行的微服务架构是一种将单个应用程序开发成一套小型服务的方法，每个应用程序都在自己的进程中运行，并与轻量级机制（通常是 HTTP 资源 API）进行通信。
这些服务是围绕业务功能而构建的，并可由自动化部署机制来独立部署。微服务只有最低限度的集中管理，可以用不同的编程语言编写，并使用不同的数据存储技术。
简单地说，微服务就是一种面向服务的软件架构，在这种架构中，服务器端应用程序是通过组合许多单用途、小容量的网络服务来构建的。微服务架构让边界设计良好的服务的失效互不影响成为可能。
微服务架构在消费互联网得到了非常良好的应用和验证。随着企业数字化转型的需求兴起，微服务的很多优势和特性也受到了企业IT团队的关注：更快的开发、更好的可扩展性、更小的独立团队、独立的部署、使用正确的技术来完成工作等等。
但是，微服务与炙手可热的分布式系统架构是否适合企业级应用，这在业内一直是有不同的声音的。很多企业IT部门在自建微服务架构系统时，往往会碰到各种各样的问题。
在这里我们总结和列举了常见的8个问题供大家参考——
01 企业开发负责人低估了开发微服务的复杂性
许多非常看好微服务的企业IT经理人认为微服务就是解决他们所有问题的灵丹妙药，但大多数技术团队及其管理者低估了微服务开发的复杂性。
要开发微服务，开发人员需要一个高效的本地环境设置。随着系统中的服务数量开始增加，在一台机器上运行应用程序的子集变得越来越困难。特别是当你使用消耗较多内存的语言（如 Java）构建应用程序时，更是如此。
下面是与本地开发设置相关的要点：
- 本地开发的第一个重要方面是要有一个好的开发机器。我发现，大多数组织想要使用所有最新的、最先进的技术，但却不想替换掉糟糕的 Windows 开发机器。开发人员受限于他们的开发机器。我曾见过开发人员使用 VDI 映像或配置交叉的机器来构建基于微服务的系统。这降低了他们的工作效率，使他们无法完全投入工作。使用糟糕的开发机器带来的副作用就是，开发人员无法得到快速的反馈。如果你知道必须等待数分钟才能运行集成测试套件，那么你就不会编写更多的集成测试套件，免得给你带来痛苦。糟糕的开发机器将会导致糟糕的开发实践；
- 一旦你为开发人员配备了合适的开发机器，那么下一步就是确保所有服务都使用构建工具。你应该能够在一台新机器上构建整个应用程序，而不需要进行太多配置。根据我在微服务方面的经验，使用能够构建整个应用程序的根构建脚本也会有所帮助；
- 下一个要点就是要让开发人员能够轻松地在他们的系统上运行应用程序的各个部分。在配置了所有端口和卷的情况下，应该使用多个 docker-compose 文件来提供不同的服；
- 接下来，如果你使用的是类似于 Kubernetes 的容器编排工具，那么你应该投资类似于 Telepresence 这样的工具，以便轻松调试 Kubernetes 集群中的应用程序。
如果组织对微服务开发的复杂性缺乏理解，那么团队的速度将会随着时间的推移而下降。
02 开发库和工具和第三方组建需要持续更新迭代确保版本兼容性
众所周知，企业应用微服务的IT项目需要应用到诸多的第三方开源组件，如将 Spring Cloud Netflix OSS 框架用于微服务，使用像 Kubernetes 这样的容器编排工具，使用 Eureka 作为服务发现工具，通过类似 Lstio 这样的服务网格降低微服务管理的复杂性。
随之而来的问题就是，要使所有服务的依赖项版本保持同步或兼容。
有一家地产行业为主的企业IT部门用 Spring Boot 来构建微服务。在过去两年中，他们已经构建了 20 多个 Spring Boot 服务。在他们的环境中，他们使用的 Spring Boot 版本从 1.5 到 2.1 不等。这意味着当有人设置他们的机器时，他们必须下载多个版本的 Spring Boot。此外，他们还缺乏自版本 1.5 以来在 Spring Boot 中所做的许多改进。
时间积累足够久滞后，这些版本的同步、兼容和维护问题慢慢成为了IT团队的技术债务项。这些技术债务项如果不去理睬很快就会出现各种各样的兼容性和版本问题，但一旦投入必要的资源投入管理和维护无疑会增加IT投入成本，这对一个本来资源就不富裕的企业内部IT团队来说是一个很艰难的选择。（未完待续）
