普元王文斌：微服务架构开发模式需要全栈团队
容器技术的发展，让微服务的构建变得容易，例如普元公司正在使用Kubenetes作为一个底层的容器调度平台来支撑上层微服务的部署运行。日前，普元普元基础设施架构师王文斌接受CSDN记者专访，介绍了他对微服务的理解，以及普元团队的微服务实践经验。
王文斌表示，微服务架构需要的技术关注点包括：基础设施自动化、服务注册、服务发现、服务路由、服务熔断、集中配置、统一日志收集、服务监控等。可选的框架有OpenStack、Kubenetes、Swarm等。选型的时候，除了考虑自身对于这些框架的熟悉度以及可掌握度，还需要从技术/功能、项目运作模式、技术提供者的背景、生态环境等方面考虑。
他还谈到，微服务架构的开发模式不同于传统方式，它将应用按业务能力来划分为不同的服务，每个服务都要求在对应业务领域的全栈（从前端到后端）软件实现，从界面到数据存储到外部沟通协作等等。因此团队的组织是跨功能的，包含实现业务所需的全面的技能。近年兴起的全栈工程师正是因为架构和开发模式的转变而出现，当然具备全栈的工程师其实很少，但将不同领域的工程师组织为一个全栈的团队就容易的多。
关于微服务和Kubenetes，您可以关注2016年7月7日的微服务与容器技术实践沙龙，分享的主要内容包括：
- 基于微服务架构的技术实践（顾伟，普元信息主任架构师）
- Kubernetes在公有云上的实践分享（严伟，普元基础设施架构师）
以下为采访内容实录：
CSDN：请先和大家介绍下您和目前所从事的工作，以及关注哪些技术领域？
王文斌：大家好，我是王文斌，现在在普元公司任职。目前所做的工作是在普元新一代企业云平台中参与基础设施这一块，基础设施是新一代的底层支持模块，主要提供租户和微服务环境资源配额，包括租户可用资源的配额，以及基于租户资源的微服务在各种环境下的资源配额（如开发环境、测试环境、生产环境等等），服务发现，负载均衡，还提供运行容器的创建、销毁、调度、复制以及持久化卷管理等能力。可以看到这些能力基本和Kubenetes提供的能力匹配，因此在新一代里就是使用Kubenetes作为一个底层的容器调度平台来支撑上层微服务的部署运行。所以Kubenetes也是我现在比较关注的技术。
CSDN：您能谈谈微服务（MicroServices）这个概念的诞生背景吗？
王文斌：微服务是由Martin Fowler提出的一种服务架构模式，和微服务相对应的，是被称为单一整体式架构。单一整体式架构是将所有的功能打包在一个WAR包里，基本没有外部依赖（除了容器），部署在一个JEE容器（Tomcat、JBoss、WebLogic）里，包含了DO/DAO、Service、UI等所有逻辑。
单一整体式架构的优点是：
- 开发简单直接，集中式管理
- 基本不会重复开发
- 功能都在本地，没有分布式的管理开销和调用开销
缺点就是：
- 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断
- 代码维护难：代码功能耦合在一起，新人不知道何从下手
- 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长
- 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉
- 扩展性不够：无法满足高并发情况下的业务需求
在现在应用功能越来越多，要支撑的用户数量越来越大，需求变更响应也要求越来越及时，应用本身就会变得越来越复杂的背景下，微服务的目的是有效的拆分应用，实现敏捷开发和部署。
CSDN：网上有人认为微服务算是一个分水岭，也是传统技术人士倒戈互联网，以互联网为代表的技术思想确立的里程碑。能否分享下您眼中的微服务，以及您对微服务的认识和理解。
王文斌：微服务和单一整体式架构都有其优缺点以及适用场景，并非使用了微服务架构应用就一定比单一整体式架构的应用更好，而应该根据实际情况去选择。Martin Fowler和James Lewis根据开发社区的讨论总结：
集中式管制的后果之一就是出现标准单一技术平台的倾向。根据经验来讲，这种办法过于严苛——并非每个问题都是个钉子，可以用一个锤子（解决方案）来搞定。
然而，有时候使用集中管制的单一整体式架构仍然是有意义的。例如，Stack Exchange的工程师VP David Fullerton这样描述单一整体式架构：这是个让人感到乏味的架构，却能造就令人兴奋的结果。他曾这样描述自己的单一整体式架构：
其规模很适合我们。我们每个月要处理40亿个请求，峰值达到3000个/秒；每天处理8亿个SQL查询，峰值达到8500个/秒。
通过该例子可以看到单一整体式架构在应用规模没有大到一定需要采用微服务的架构时还是有其适用场景的，单一整体式架构在时间有限时，能提供非常清晰的路径，关键是可以尽快建立并运行起来。如果整支团队已经集中在一起，并取得同步，就能更有效地协作，继续完成任务。部署很简单，扩展起来也相对简单。团队只需要在大量虚拟机或独立主机上通过负载平衡器运行多个副本。一般来讲，团队最终会构建出单一整体式架构的核心，然后通过微服务手段构建可扩展组件。
CSDN：微服务能够解决我们哪些的难点、挑战和痛点？
王文斌：像前面说的，随着现在应用功能越来越多，要支撑的用户数量越来越大，需求变更响应也要求越来越及时，应用本身就会变得越来越复杂，微服务可以可以有效的拆分应用，实现敏捷开发和部署。
使用了微服务，无论是应用自身，还是团队磨合，都会有很严重的沟通问题。当然，微服务在文档、测试与解决不兼容问题的时间上肯定有着更高的阈值。
服务之间如何通信？
服务间的通行就是IPC（inter process communication），已经有很多成熟的方案。现在基本最通用的有两种方式：- 同步调用：REST（JAX-RS）/RPC（Dubbo）
- 异步消息调用：Kafka/RabbitMQ
同步调用比较简单，一致性强，容易出调用问题，性能体验上也会差些；异步消息的方式在分布式系统中有特别广泛的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能保证调用方的服务体验，继续干自己该干的活，不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱，需要接受数据最终一致性。
这么多服务，怎么找?
这就是服务发现的问题了。一般有两类做法，也各有优缺点。基本都是通过ZK等类似技术做服务注册信息的分布式管理。当服务上线时，服务提供者将自己的服务信息注册到ZK（或类似框架），并通过心跳维持长链接，实时更新链接信息。服务调用者通过ZK寻址，根据可定制算法，找到一个服务，还可以将服务信息缓存在本地以提高性能。当服务下线时，ZK会发通知给服务客户端。- 客户端做：优点是架构简单，扩展灵活，只对服务注册器依赖。缺点是客户端要维护所有调用服务的地址。
- 服务端做：优点是简单，所有服务对于调用方透明。
服务挂了怎么办？
当我们的系统是由一系列的服务调用链组成的时候，我们必须确保任一环节出问题都不至于影响整体链路。相应的手段有很多：- 重试机制
- 限流
- 熔断机制
- 负载均衡
- 降级
CSDN：与传统单块架构相比，微服务架构有哪些特点？
王文斌：微服务架构主要特点如下：
通过服务实现组件化
传统实现组件的方式是通过库（library），传统组件是和应用一起运行在进程中，组件的局部变化意味着整个应用的重新部署。通过服务来实现组件，意味着将应用拆散为一系列的服务运行在不同的进程中，那么单一服务的局部变化只需重新部署对应的服务进程。另外将服务作为组件可以更明确的定义出组件的边界，因为服务之间的调用是跨进程的，清晰的边界和职责定义是设计时必须考虑的。按业务能力来划分服务与组织团队
任何设计系统的组织，最终产生的设计等同于组织之内、之间的沟通结构。传统开发方式中，我们将工程师按技能专长分层为前端层、中间层、数据层，前端对应的角色为UI、页面构建师等，中间层对应的角色为服务端业务开发工程师，数据层对应着DBA等角色。事实上传统应用设计架构的分层结构正反应了不同角色的沟通结构。而微服务架构的开发模式不同于传统方式，它将应用按业务能力来划分为不同的服务，每个服务都要求在对应业务领域的全栈（从前端到后端）软件实现，从界面到数据存储到外部沟通协作等等。因此团队的组织是跨功能的，包含实现业务所需的全面的技能。近年兴起的全栈工程师正是因为架构和开发模式的转变而出现，当然具备全栈的工程师其实很少，但将不同领域的工程师组织为一个全栈的团队就容易的多。服务即产品
传统的应用开发都是基于项目模式的，开发团队根据一堆功能列表开发出一个软件应用并交付给客户后，该软件应用就进入维护模式，由另一个维护团队负责，开发团队的职责结束。而微服务架构的倡导者提议避免采用这种项目模式，更倾向于让开发团队负责整个产品的全部生命周期。Amazon对此提出了一个观点：You buidl it, you run it.
开发团队对软件在生产环境的运行负全部责任，让服务的开发者与服务的使用者（客户）形成每天的交流反馈，来自直接客户端的反馈有助于开发者提升服务的质量。
智能终端与哑管道
微服务架构抛弃了ESB过度复杂的业务规则编排、消息路由等。服务作为智能终端，所有的业务智能逻辑在服务内部处理，而服务间的通信尽可能的轻量化，不添加任何额外的业务规则。去中心统一化
传统应用中倾向采用统一的技术平台或产品来解决所有问题。不是每个问题都是钉子，也不是每个解决方案都是一个锤子。问题有其具体性，解决方案也应有其针对性。用最适合的技术方案去解决具体的问题，在大一统的传统应用中其实很难做到，而微服务的架构意味着，你可以针对不同的业务服务特征选择不同的技术平台或产品，有针对性的解决具体的业务问题。基础设施自动化
单一进程的传统应用被拆分为一系列的多进程服务后，意味着开发、调试、测试、集成、监控和发布的复杂度都会相应增大。必须要有合适的自动化基础设施来支持微服务架构模式，否则开发、运维成本将大大增加。Design for failure
正因为将服务独立在不同的进程中后，引入了额外的失败因素。任何时刻对服务的调用都可能因为服务方不可用导致失败，这就要求服务的消费方需要优雅的处理此类错误。这其实是相对传统应用开发方式的一个缺点，不过随着一些开源服务化框架的出现，对业务开发人员而言适当的屏蔽了类似的错误处理，不过开发人员依然需要知道对服务的调用是完全不同于进程内的方法或函数调用的。进化设计
一旦采用了微服务架构模式，那么在服务需要变更时我们要特别小心，服务提供者的变更可能引发服务消费者的兼容性破坏，时刻谨记保持服务契约（接口）的兼容性。对于解耦服务消费方和服务提供方，伯斯塔尔法则（Postel’s law）特别适用：发送时要保守，接收时要开放（Be conservative in what you send, be liberal in what you accept.）。
按照伯斯塔尔法则的思想来设计实现服务调用时，发送的数据要更保守，意味着最小化的传送必要的信息，接收时更开放意味着要最大限度的容忍信息的兼容性。多余的信息不认识可以忽略，而不应该拒绝或抛出错误。
CSDN：微服务架构是否适用于互联网应用？为什么？
王文斌：微服务是比较适合互联网的，还是前面说的，随着应用功能越来越多，要支撑的用户数量越来越大，需求变更响应也要求越来越及时，应用本身就会变得越来越复杂，这时候会更需要采用微服务架构来拆分应用，实现敏捷开发和部署。
CSDN：微服务架构是当前互联网业界的一个技术热点，各自公司都有计划开展微服务化体系建设，不过，一个微服务架构有哪些技术关注点？需要哪些基础框架或组件来支持微服务架构？这些框架或组件该如何选型？
王文斌：一个微服务的架构需要的技术关注点大概包括：基础设施自动化、服务注册、服务发现、服务路由、服务熔断、集中配置、统一日志收集、服务监控等。可选的框架包括如OpenStack、Kubenetes、Swarm、Hystrix、SpringCloud、ELK、Kafka、RabbitMQ、Zabbix、cAdvisor等。
对于如何选型，除了考虑自身对于这些框架的熟悉度以及可掌握度，还需要考虑的是：
- 技术/功能
- 技术架构
- 功能特性
- 开发语言
- Roadmap
- 项目运作模式
- License
- 是被一家公司掌控还是松散的集体决策社区开发？
- 技术提供者的背景
- 产业经验
- 提供者自己有没有大规模使用？
- 是从自身需求沉淀出来的产品还是按设想的需求开发的产品？
- 生态环境
- 技术和技术提供者在产业链中的位置
- 与友商的合作/竞争关系
- 是众望所归还是单打独斗？
CSDN：微服务架构下Docker怎么玩？您有什么心得和体会可分享？
王文斌：微服务适很合作为一个Docker镜像进行打包部署，当微服务与容器结合使用时，微服务架构所具备的优势将被进一步放大。微服务鼓励软件开发者将整个软件解耦为较小的功能片段，并且这些功能片段能够应对外界的故障，这为我们带来了敏捷性和适应性。而Docker将我们的软件从底层的硬件中进行解耦，这为我们带来了在基于虚拟机的解决方案中见所未见的可移植性与速度。基于镜像可以做到微服务的快速部署、回退、版本升级，并且和Kubenetes结合时，可以保证微服务的高可用，以及做到服务的发现、路由，以及负载均衡。
CSDN：微服务器骤然兴起，企业的接受也需要有过程，在市场开拓等方面，您如何考虑？
王文斌：传统大型企业对于基于容器的微服务的新架构可能相对保守，而且他们的应用建设一般都是按周期划分，每个周期时间相对较长（一般10年左右），因此在没有很大的外力推动下（如上线周期要缩短、需要响应要更快等）不太会去重构已有应用。而且采用了新架构可能对于企业IT已有的组织结构也会有一定影响。所以可以先考虑把这种基于容器的微服务架构引入到应用的开发/测试环节中以提高开发/测试的效率，然后再逐步引入到非核心的应用的生产环境以确保稳定性，最后再推广到整个企业全面使用新架构。
CSDN：能否简单介绍一个微服务架构实践的典型案例？
王文斌：普元的新一代企业云平台可以算是一个采用了微服务架构的平台，整个平台分成多个领域系统，如SCM、SRM、SEM等，这些领域系统就是一个个微服务。领域系统都是一个个独立的Java进程，系统之间采用REST接口调用。各系统是跑在了一个我们内部开发的称之为MSF的框架上，MSF负责了服务发现和路由、服务调用重试、服务熔断以及服务监控等功能。
王文斌，普元基础设施架构师，骨灰级软件工程师，代码高手，开源技术爱好者，容器技术专家。兵来将挡，水来土掩的全能架构师。