近几年，微服务和中台的概念异常火爆，这阵风已经从互联网公司，吹到了传统企业信息化建设领域，几乎在任何一个企业信息化建设相关论坛中都会涉及到。俗话说，外来的和尚好念经，不少有数字化转型诉求的传统企业或机构组织，不管其领导人是否懂技术，都已经被或多或少地洗脑了。
但一方面，互联网公司基于自身的业务特点持续迭代和演进出来的技术体系，是否适用于所有传统企业？另一方面，传统企业在模仿互联网公司构建自己的信息化系统时，是否正确理解和落实了这些技术理念，还是仅仅照猫画虎？
先说说微服务。
很多人认为，微服务的核心就是拆分。大功能太复杂，不好一次实现，但是拆分成一个个小功能后，每个小功能都单独实现，这就简单很多。此外，还可以将那些能够为多个应用提供服务的通用性功能拆分出来独立实现，以减少重复开发。
但是，没有微服务概念之前，我们的系统就没有拆分了吗？举例来说，有经验的程序员都会将常用的代码片段重构为公用函数；而在对象设计时，也都会将具有独立业务意义的功能设计成一个独立的类。
其实，微服务的核心理念是：只做一件事，并把它做到极致。而围绕这一理念，微服务是有着管理层面和技术层面的两种解读方式的。
在管理层面，微服务通常是与企业组织架构相关联的，组织架构中会形成不同的团队去维护自己的微服务，这个团队会对自己维护的业务更有归属感，形成自治，从而激发团队的主观能动性，释放各个团队的创新能力，这就自然形成了企业想要的扁平化管理。
但就目前来说，提到微服务，则越来越多地聚焦于其在技术层面的具体实现方式了，进一步说，就是企业该通过什么样的技术架构，来支持应用的微服务化。那么，微服务架构具体有什么标准化的技术层面的清晰定义呢？
如果我们解读一下现在一些头部互联网公司展示出来的它们各自的技术框架，就会发现，其实每家公司都有自己不同风格的微服务架构。但总的来说，我们还是可以通过一些原则来归纳出微服务架构的基本特征的：
1：系统由两个及以上服务组件组成，这些组件将其自身功能以服务的形式展现出来，并按照预先定义的协议进行交互，每个组件服务对应一个业务目标，各个服务组件之间是松耦合的；
2：系统应该是与编程语言无关的，某一个服务组件可以用Java 开发，与此同时，另外一个服务组件可以用.NET开发，单独某一个服务组件在实现时的技术选型，不会影响到整个应用架构；
3：系统的数据库应该是去中心化的，每个服务组件都可以享有自己的数据库，且该数据库仅供该服务组件自己使用，任何其他服务组件都不能读取或者修改该数据库中的数据；
4：系统中的每个服务组件都是可以自行部署和测试的，任何一个服务组件在测试、部署和运行的时候都不应该依赖其他服务组件或者资源；
5：任何一个服务组件的故障都应该是隔离的，单个服务组件的故障不应该拖垮整个应用，也不应该影响其他服务组件。
以上五项原则，基本是适用于所有微服务架构的，不过对于这样的微服务架构，在很多长期为传统企业设计信息化系统的人来看，与所谓的共享服务、能力开放等，并没有本质区别，难道那些传统企业的信息化系统，一直都是在遵循微服务架构来设计开发的么？
事实上，传统企业进行信息化系统开发时，确实也会规划一些能力开放组件，形成一个共享服务层，供上层业务调用，这也的确符合上面的五点原则。不过，微服务架构的概念毕竟是从互联网公司叫起来的，而互联网公司的系统相比传统企业的信息化系统的区别包括：数量极多的服务组件、各个服务组件的持续和频繁的迭代，以及极为灵活和复杂的服务调用。所以仅仅将共享功能组件堆砌在一起，即便可以从系统逻辑上划分出一个中台微服务层，但却不能称之为被业界所公认的微服务架构。而完整的微服务架构，还应该具备下面四点特征：
1：系统应该有自动化测试能力，因为对于互联网公司来说，很多微服务组件，版本迭代都非常频繁，且涉及到的前端服务调用也较为复杂，所以微服务在构建、测试，到上线的整个周期中，如果没有自动化测试，微服务架构速度快的特征，就是一纸空谈。
2：相比传统企业信息系统中较少的共享服务，互联网公司的服务组件非常多，所以需要有非常强的服务治理能力，包括服务注册、服务发现、配置管理、监控限流、路由分发、网关调用、负载均衡，以及链路追踪等等
3：同样，对于互联网公司大量且迭代频繁的微服务组件，其部署运维工作，仅靠人工操作将很难支撑，每个组件必须能够实现便捷的持续集成、持续部署、持续监控、持续反馈和持续改进，这一系列流程的实现，应该有一套支持开发运维（DevOps）的高效工具链。
4：此外，基于云的容器服务，能够让整个微服务架构有一个好的基础设施层支撑，从而能够快速地进行服务组件的部署和交付，因此也可以看作是微服务架构的重要组成部分。
关于微服务的更多干货，这里还有本[微服务实践]电子书，系统地介绍了微服务的相关知识，有兴趣的朋友可以联系获取。
下面再说说中台。
中台是以核心能力微服务化为中心，去支持上层应用的快速创新、快速响应和快速迭代，同时消除烟囱式子系统、避免重复造轮子，以及拉通信息系统，重塑组织协同。
中台和微服务架构，可以看作是有交集的两个领域的概念，中台更偏业务、偏战略、偏组织；而微服务架构则更偏重具体的技术实现。
微服务架构可以看作是实现中台战略的技术手段，但却不代表中台的全部。而作为一种系统架构，微服务架构不仅仅可用于中台，逻辑上位于前台和后台的功能组件或系统，同样能够以微服务化的形式进行开发和实现。不过，由于中台的定位就是共享服务中心，所以微服务架构的价值和优势能够得到更为充分和突出的展现。
最后再来说说，为什么很多互联网公司构建中台以及进行微服务架构改造都取得了成功，而不少传统企业在构建和规划中台和微服务架构的过程中却会碰到各种问题呢？
众所周知，几乎所有成规模的互联网公司，都有极为丰富的产品线和功能模块，以及在不同产品或功能模块中产生的海量数据。互联网公司在设计“中台”战略和微服务架构时，是希望其能够解决企业级能力在其不同的产品和功能模块中的复用问题，以及打破相互之间的数据壁垒。相应的，典型的中台也就大致分为业务中台和数据中台两类，并分别承担不同的职责。
但传统企业的信息化系统，是否有这样的问题亟待解决呢？或者换个说法，具备下面至少两点特征的传统企业，才是有可能需要“中台”的：
1.企业要具备一定规模，信息化建设达到了一定水平，应用系统较多，且有较多的面向C端海量用户的业务产品，并有海量的数据积累；
2.企业内部有多条业务线或多级组织架构，且各个业务单元或各级组织，都有自己的系统，且各个系统中存在很多重复建设的功能模块；
3.企业的互联网前端业务越来越多，包括APP、小程序、网站等等，且前端业务需要不断响应用户需求、持续创新、快速迭代。
对于不具备两点以上特征的企业，盲目追求技术的“先进型”，强行构建中台以及进行微服务化改造，重构和迁移现有系统，很可能会是一件得不偿失的事情。这不仅仅在于高昂的成本换不来多少效益，而更重要的是，中台和微服务架构能够帮企业解决的问题太少，却可能因为增加了系统的复杂性，而多了很多设计和运维成本。
此外，在更高的企业管理层面，中台也对企业的战略或组织架构提出了新的要求。如果传统企业没有与中台战略相匹配的管理理念和组织架构层面的调整，那么微服务与DevOps也是无法顺利推进下去的，中台战略很可能会名存实亡。
创作不易，欢迎朋友们关注、评论、转发。如商业转载或其它，请联系作者。