微服务的这些坑不能碰

  如今，微服务可谓是风靡一时。Forrester发布的一项研究之后发现，76%的企业正以微服务架构为指导进行应用程序重构。

  但需要强调的是，微服务绝不是什么万灵丹药。在一项面向生产环境内微服务应用的研究中，我们正真看到59%的收房的人说每种微服务都会给数据管理等运营事务带来新的挑战。更令人担忧的是，这份报告还提到在对不同环境内的故障排查难度作比较时，73%的收房的人说微服务环境难度更大，只有21%的受访者认为单体式架构难度较大。

  但为什么会出现这样的状况？根据BCG Digital Ventures公司工程技术培养和训练副总裁Matthew Sinclair的解释，是因为技术专家们总是想用最现代的技术解决实际问题，即使他们对很多新兴技术还只有少数的经验。“但作为工程师，我很理解其中的选择思路。这么做不是因为更安全，而是因为能让从业者学到更多新东西。”他说。

  客户们在听说微服务这项新技术的消息之后，总觉得应该用新方法解决自身的整体问题。于是，他们热衷于向软件工程师介绍微服务架构，调动起工程师们的积极性，之后就是在软件工程建设项目中迅速添加大量微服务元素。

  但问题在于，整个开发流程不可能一夜之间完成由单体式架构到微服务架构的转换。换言之，企业在微服务迁移方面往往操之过急一听说其中的优点、了解到部分收益，就想把它全面推向各个角落。正因为如此，一些公司开始不可避免地陷入微服务误区。

  我们必须意识到，微服务架构代表的是一种分布式系统，因此不妨以部分员工已经具备经验的分布式思维进行设计。此外，千万别忘了这样一条黄金准则：如非必要，勿增实体。

  换句话说，大家必须明确自己为何需要构建某种事物、想要借此达成怎样的目的。这是个最基本的问题，适用于任何规模的企业。打算解决什么样的问题、解决之后能够给用户所带来怎样的收益，才是决定是不是使用某种技术的根本前提。

  用户们其实也并不关心底层技术究竟是什么他们不关心怎么来实现，只关心能不能解决问题。

  如果唯一的实现方法就是微服务，那我们毫无疑问应该着手使用。但若还有其他替代方法，请第一先考虑这些替代方法。绝对不能陷入“为了微服务而微服务”的怪圈。

  总而言之，微服务是一种旨在降低复杂性的架构模式。而一旦使用，它又会在其它层面增加复杂水平。如果孤立使用微服务，那么某一维度中得以解决的复杂性，必然会在某种形式扩散到其他领域。因此，最重要的是使用多种其他工具将组织的整体复杂性控制在最低程度。

  这又回到了之前的拷问：我们要解决什么样的问题？如果大多数企业可完全通过传统且常规的技术搞定当前需求，那么无需选择微服务。不要看到Amazon和谷歌等科技巨头全面实施微服务，就跃跃欲试。请先问问自己，微服务对我们来说是不是正确的选择。

  也有不少企业掌握着重要的旧代码库，而且与业务体系严密集成。同样的，微服务也许并不适合这种状况。因此，尽量只在云原生项目中使用微服务，同时继续沿用旧有技术处理传统IT领域的挑战。

  一次又一次，我们总会回到最基本的考量：我们要用产品或技术解决什么样的问题？注意，不是怎么样才能解决，是解决什么。若用户与你的产品做交互，能够得到哪些收益？只有为这样的一个问题找到明确的答案，大家才能判断微服务架构是不是适合自己。

  以上内容与证券之星立场无关。证券之星发布此内容的目的是传播更多详细的信息，证券之星对其观点、判断保持中立，不保证该内容（包括但不限于文字、数据及图表）全部或者部分内容的准确性、真实性、完整性、有效性、及时性、原创性等。相关联的内容不对各位读者构成任何投资建议，据此操作，风险自担。股市有风险，投资需谨慎。