时至今日，微服务框架已经从炒作逐渐转化为切实可行的方案。整个技术行业开始意识到，我们很难单纯通过在现有组件之上开放HTTP接口的方式构建起符合微服务规范要求的系统。虽然很多组织机构明确表示，架构及其编排的重要意义丝毫不低于基础设施优化、文化转型乃至组织调整等事务，等大部分Java开导得仍然很难把握具体的系统架构，或者说很难将微服务与分布式系统区分开来。而这些认知恰好是决定项目成败的关键所在。在今天的文章中，我们将通过问答的形式对此作出阐述。
为什么要重提微服务?我们难道不能继续编写EBJ及Servelet吗?
微服务的关键在于以独立性方式支持应用的快速演进。另外，其应该能够实现独立扩展且资源需求量较基于服务器的应用程序更低。考虑到业务需求的不断变化以及应用程序客户量的不断增加，集中式基础设施在运营以及针对不可预测负载乃至负载峰值时会带来过于高昂的成本。如果继续坚守应用服务器，则根本不可能实现Netflix、Twitter或者Amazon这类解决方案。
微服务属于分布式系统。前者有何特别之处?
分布式系统的初始概念为：“分布式系统是指一套其中各组件位于联网计算机当中，并通过发送消息实现彼此通信与协作的模型。”这一点也同样适用于微服务架构。
个别服务被部署在云实例当中，并通过交换信息的方式实现运行功能。这一思路与集中式应用程序构建存在巨大差别。相较于在数据中心内设置大量服务器用以处理各类同步、事务及故障场景，现在我们开始以独立形式开发个别服务且各服务间互不影响。当然，分布式计算也会带来一些特殊的基础性挑战，具体包括容错、同步、自我修复、背压以及网络划分等等。
分布式系统是否正是人们所说的反应性系统?
实际情况更为复杂。坦率地讲，如今很多概念都会使用“反应性”一词。要利用多个独立微服务构建起应用程序或者系统，大家需要利用各项设计原则以实现其彼此反应性、弹性以及消息驱动能力。也许这听起来颇为熟悉——没错，Reactive Manifesto给出的定义正是如此。
能够实现Reactive Manifesto提出的四大特性的分布式系统即可被称为反应性系统。举例来说，Lagom框架就基于这些基本原则，但具体来讲，大家并不需要利用特定框架或者产品来构建此类应用，因为这类框架或产品只是为了提升执行效率。
我们可以利用哪些选项构建一套基于微服务的系统?
我个人认为目前的微服务呈现出两种解决问题的趋势。其一为将问题下移，从而将其交由编排、数据中心或者云系统负责解决。第二种解决方案则是立足应用程序或者框架层面进行本地解决。
每服务一容器，为什么不能让容器容纳更多应用元素?
这里我们先来讨论之前提到的种方法。编写一项微服务，将其与运行时一道打包在小型容器内，而后将其推送至云端。作为全栈DevOps开发者，大家应该能够轻松创建起云运行时所必需的元信息。另外，我们也能够凭借着详尽的监控信息轻松检测到失败服务并对其进行重启。另外，也有很多神奇的框架(NetflixOSS)有助于应对分布式系统中的各类挑战。
就个人而言，我认为这种方案的弊端在于缺少与基础设施的紧密耦合。这意味着整套系统无法在选定的平台之外运行。另外，有人认为可以单纯依靠容器技术解决微服务领域的所有难题。但通过回顾Reactive Manifesto，大家就会意识到这类系统无法帮助我们实现服务之间的信息传递要求。
没有容器作为辅助的微服务?这可能吗?
诚然，容器技术拥有一项更大的优势：将完整堆栈以可控方式打包为单一可部署单元。其在基础设施层面来看可算是一种隔离机制。而容器标准本身亦是一项助益，意味着我们的容器更易于保存及使用。但这还远远不够。要构建起具备弹性与自我修复能力的系统，我们需要能够容纳错误、将其定义为信息、将信息发送给其它组件(即监控型组件)并在故障组件之外进行安全管理。而这一切需要信息驱动型机制方可实现：远离强耦合、脆弱及深层嵌套当中的同步调用链，转而让各个组件拥有容错能力……或者忽略能力。我们的思路是对调用链内的故障管理机制进行去耦，意味着客户不再需要负责处理服务器故障。很明显，没有哪种容器或者编排工具能够实现这样的效果。大家需要进行事件溯源。事件驱动型架构正因为在设计概念中考虑到了事件溯源，因此能够很好地同微服务架构模式进行配合。
反应性编程、系统、流程：是否都属于同一回事?
反应性已经成为一个被滥用的词汇，目前不同的人对其有所不同的理解——在出色的企业中，其代表着“流式”、“轻量化”以及“实时”等含义。反应性编程能够通过性能与资源效率等角度提升开发者生产力，且立足于内部逻辑与数据流管理的组件层面。反应性系统则帮助架构师与DevOps团队通过弹性能力实现生产力提升，立足于云原生或者其它大规模分布式系统的系统构建层面。
杨经理 