许多创新创业者，包括谋求转型的传统企业，在启动互联网业务开发时，更多的会从产品和运营的角度对研发提出需求，而并不会对具体的技术实现方式进行太多过问。他们觉得，能找到理解产品需求，帮忙开发产品的人或外包团队就可以了，至于对方具体怎么实现，则或者不关心，或者不懂，反正最终能做出像模像样的产品来就行。

在传统产业中，企业负责人会去对农业工艺、工业工艺、建筑工艺等进行充分了解，甚至成为这些方面的半个专家，因为他们知道，这些是企业进行生产经营的基础。而在互联网领域中，技术是产品的基础，也就是生产经营的基础，日常运营都要围绕其展开，表面上功能相似的两款产品，在性能和体验上很可能会存在极大差别，这背后可能都是技术的差异。

许许多多腹死胎中的创新创业项目，表面上看可能是死于产品或运营，但实质可能是在于技术层面的先天不足。所以企业负责人应该积极地去了解一些技术概念，至少明白大致原理，包括是否符合技术发展潮流以及采用的成本和带来的好处等等，从而帮助自己判断其是否能够支撑创新业务的发展和市场竞争。

顺便提一句，我们的内容重点面向那些对互联网科技不甚理解的创新创业者和传统企业管理者，希望帮助他们正确认知互联网，了解重要的科技趋势，以便能够在进行创新或转型时，适度补齐自己的短板；资深专业技术人员可能会觉得内容比较基础，甚至存在为了通俗易懂地解释而出现的瑕疵。

什么是微服务

自2014年被明确提出以来，微服务架构受到了前所未有的关注，众多互联网巨头开始实施微服务架构并取得了不错的效果，甚至目前会有一些技术创业公司，专门帮助一些大型传统企业，将其原有的企业应用进行“微服务化”改造。

微服务是一种应用的架构风格，一个软件应用可以由很多个微服务组成，系统中的各个服务之间是松耦合的，通过接口进行通信，每个服务代表着一个小的业务能力，可以使用不同的编程语言实现，可以基于不同数据存储技术，可以独立部署和独立维护。例如可以将一个应用拆分为注册登录、检索、详情、评论、推荐、交易等多个小服务，它们组合在一起后，共同构成这个应用。

可能有人知道，常规应用开发中也会提到比如模块化、可扩展之类的概念，甚至听说过SOA（面向服务的架构），这些架构也都是为满足业务需求的不断调整而服务的，但强度和灵活性不同，举一个例子大致谈谈区别：

模块化：相当于公司的业务部门，开发、产品、运营、市场等，分别有自己的团队，共同结合在一起才能发挥作用，成为一个单体应用，单独某一个部门是不能脱离其它部门独立运行的，这是其相对SOA和微服务的最大差异。

SOA：将应用内部按照子项目进行拆分，比如PC应用团队、APP团队、小程序团队、后台团队等等，并有统一的横向部门协调管理（企业服务总线，APIs层），这些团队的业务，共同结合在一起，可以作为一个单体应用，同时各个团队的服务也能够独立运行和维护。

微服务：SOA已经实现了对单体应用的服务拆分（松耦合），但只是相对粗颗粒度的拆分，而微服务则是更细颗粒度的服务拆分。微服务将应用内部按照具体业务功能进行拆分，例如注册、登录、评论、私信、即时消息、购买交易等等，都可以作为单独服务，并且不存在一个企业服务总线调度，而是各个服务之间自主发现和调用其它服务，且可以是跨终端跨平台的调用。

微服务架构的优点

微服务架构大体是从互联网企业兴起的，由于互联网产品功能复杂，而很多业务模块之间的关系呈漏斗模型（即有的功能使用量很大，有的功能使用量极小），所以这就对不同业务模块的负载均衡、用户体验、创新价值、升级更新（迭代）周期以及数据处理分析提出了差异化的要求，因此需要对应用架构进行调整。

微服务架构有如下好处：

1.单个微服务功能聚焦，能降低复杂性，彼此之间松耦合，能够被独立开发和部署，可以选择适合自己的开发语言和数据存储技术。

2.单个微服务对应的小团队可以独立工作，进行相应的产品创新，而新加入某个团队的新成员（开发、产品、运营等），可以快速了解业务，快速上手。

3.微服务可以在不影响全局情况下进行升级、替换、扩展及进一步拆分。

4.不会因为一个服务不可用而影响了整个业务（除一些入口服务出现问题外，比如评论服务不可用，不会影响到购买服务等）。

根据以上分析，不难看出，微服务与上一篇文章提到的“两个披萨原则”简直就是天生一对儿。正因为有了“两个披萨原则”，有了微团队，才对应用的技术架构的“微服务化”提出了需求，微团队在进行项目开发和运营时，才有了完全可控的自有阵地。

微服务架构的不足与建议

当然，微服务也会有一些潜在的问题：

1.微服务过多会对开发和运维带来挑战，代码虽然被拆分到各个微服务中了，各个微服务也可以独立部署了，但总的代码量和部署工作是增加了的。

2.分别独立部署的微服务系统包括数据系统比单体应用架构复杂，难以管理。

3.微服务过多，也会提升服务管理的复杂性，包括技术层面的管理以及业务层面的管理，同时可能会出现重复造轮子的情况，例如某个微服务跨终端调用做的并不好，而某个有需要的终端自己再开发或拆分出一个类似的微服务出来。

可见，微服务的优势和劣势都是比较鲜明的，但我们不能脱离业务谈技术架构。微服务之所以成为互联网公司的新宠，是与互联网公司的产品复杂度、用户规模、业务创新机制和团队组织模式密不可分的。

而创业企业或传统企业在进行互联网产品开发时，单纯地为了微服务而微服务化，甚至花费巨大成本进行微服务化改造，可能在抛弃了单体应用或SOA架构优势的同时，又无法发挥微服务的优势，这是得不偿失的。

总的来说，如果创新的产品非常依赖于一套自主开发的互联网应用（如SaaS业务），而这个应用未来规划的功能会比较丰富，用户规模和运营数据也预期会比较庞大，且需要不断升级迭代，那么需要认真考虑是否采用微服务的应用架构了。否则，采用常规的模块化开发或基本的SOA架构可能已经足够了。

至于如果采用微服务架构，服务如何拆分才能达到最优效果等具体操作层面的建议，这就是另一个层面的内容了。

本文系“科技无忧网”原创，如转载请附出处。认知互联网，解读新科技，助力创业创新及传统企业转型，有问必答。