微服务落地是否值得？考虑技术与组织问题的复杂性和风险定位

微服务、容器化和DevOps的推动，不仅仅是一个技术问题，更是一个组织问题。在推动微服务落地的过程中，可以明显感受到康威定律的作用，并且需要高层级的技术总监或者CIO的介入，才能够真正推动微服务的实施。 首先，要向传统企业朋友说明一个观点：如果你们企业没有遇到足够的痛点，就不要盲目地去推行微服务，因为其中存在陷阱。实际上，微服务的落地是一个非常复杂的问题，涉及到IT架构、应用架构和组织架构等多个方面。 通过对多家传统行业企业的走访和实施微服务的经验，发现微服务的实施问题远不仅仅局限于技术层面。开始以为微服务只需要重构应用，实施微服务治理，比如注册、发现、熔断、限流、降级等等，这些工作通常从应用开发组入手，初始的讨论会比较轻松愉快。从单体架构演进到SOA，再到微服务架构，从Dubbo聊到SpringCloud，这些都是大家共同探讨的方向。 然而，实施微服务必然涉及到发布和运维问题，也就是说会牵扯到DevOps和容器层面。而这些问题都不在开发组的控制范围内。一旦涉及到运维组，对于容器的接受程度就成了一个问题，容器与传统的物理机和虚拟机存在差异，会带来新的风险等等。特别是容器本身并非轻量级的虚拟化，这并不是一时半会儿就能够完全理解的。 更重要的是，即使能够解释清楚，还有线上应用的容器化问题。一旦出现问题，责任归属的问题就会出现，容器往往造成应用层和基础设施层之间的界限模糊，这使得责任的承担变得棘手。有些企业的微服务化是由运维部门发起的，他们已经意识到各种各样不统一的应用给运维带来的困扰，并且乐意接受容器化的运维方式。 因此，微服务的落地需要面对这些复杂的问题，并需要在IT部门的专业人员和高层决策者之间进行有效的沟通和合作。在推动微服务实施的过程中，要考虑到康威定律的作用，即组织架构会影响系统设计的结果。因此，需要高层级技术领导的介入，能够有效地协调各部门之间的关系，推动微服务的顺利实施。 总之，微服务、容器化和DevOps的推动是一个复杂的问题，不仅仅局限于技术层面，更需要注重组织和沟通的层面。企业在决定是否落地微服务时，需考虑现有的痛点和组织能力，并且在实施过程中需要注重各个部门的合作和配合，才能够真正实现微服务的落地和应用。