互联网市场是一个“快鱼吃慢鱼”的市场，想要击败别人在市场占有一定份额，就要及时提升自己技术。快速响应瞬息万变的市场正是技术价值体现之一。

例如，在大的商业环境里有许多不同的业务，每个业务的技术诉求也是不同的，可能是快速上线或者高并发或者按时交付等等诉求。

技术方案是为了满足这些对技术的诉求，这也是技术的价值体现。

总结而言，技术本质上是为业务服务，无论是架构师还是底层开发，都应重视业务与技术的结合。

这里的“快”指的是一如既往的持续性的“快”，而不是断断续续的。而且随着公司规模变大，业务增多，出于成本的考虑，我们会更希望从技术上提升系统和开发人员的效率。

下面是一个在公司里经常会发生的情况。

业务人员提出一个希望能尽快上线的需求，但技术人员需要比较长的时间进行开发。这时候，产品和开发沟通后，可能会提出做一个简单的方案临时使用，后期再进行优化。

但随着时间的推移和其他客观原因，临时方案最后就变成了最终方案。在这样的场景下，极有可能会为未来埋下隐患。

在这个事例里解释了三个问题：

1. 为什么有些系统会越来越乱。

2. 这样的做法下并不是真正的快，只是为了快速满足业务的需求，搭建了一个存在问题的系统。

3. 不要相信产品说的临时方案，临时最后都会变成最终方案。

   
   

1.业务妥协欠下的业务债。也就是所谓的“临时方案”。

2.系统无秩序的增长。这主要体现在系统越来越大，代码愈加冗余，模块间耦合度高。上线质量差，为了解决一个BUG结果引入更多的BUG是我们当时经常遇到的情况。

3.研发人员的流动。核心研发人员离开之后，新的研发人员对之前的文档和系统都不够了解，导致让“接码侠”来维护系统，系统越来越差。

接码侠

在中大型团队中，存在一些很大很乱的系统，很少有人敢去维护，但系统对业务又十分重要。此时公司可能会招一些人维护系统，新招的人被称作“接码侠”

• 短期看来促进业务发展，长期看来阻碍业务发展。在最开始为了支持业务，系统越做越大，但发现把系统作大后对业务的支持越来越差。

• 具有一定普遍性。

• 解决问题变得心有余而力不足。一开始发现问题的时候，认为问题可以忍耐。直到无法忍耐的时候，发现解决变得十分复杂。

微服务没有一个固定的标准，更多的是经验的总结。因为它不是被发明出来的，而是从现实世界中总结出来的一种趋势和模式。

下面的内容，将会介绍途牛团队的经验，告诉各位在什么时候如何去做。

• 面向服务：把一个系统按照提供服务类型的不同，拆分成不同的服务。

• 单一职责：每个服务只做自己的事情。

• 微：每个服务下的团队小。

• 自治：每个微服务有自己的独立通道，不会相互打扰。

在拆分之前，要问自己三个问题：

1.是否下定决心。因为微服务需要投入大量的资源，还会有失败的可能。

2.是否对自己的业务系统有充分的了解。如果对自己的系统没有充分的了解，不建议做微服务，否则会有极高的风险。

3.是否具备实施微服务的条件。技术上的自动化水平；团队的组织架构的管理；公司或者整个行业是否支持微服务。

下面我们将以旅游系统为例，讲解微服务的拆分。

团队将系统拆为三个层面：应用层、服务层和支持层。

应用层：对业务模型进行分类，分为不同的主体。

服务层：把业务的功能按照服务的内容进行分类，并把服务从上自下的逐步细化。

支持层：是技术支持的主线，比如有服务框架、容器、监控等。

问题

• 基础公共服务抽象。例如发票服务是通用的服务，不需要每个业务都实现一遍，可以将其提取成一个公共的服务。

• 服务拆分的边界。对于有些服务按照不同的划分规则会被拆分到不同的服务内，所以在最开始时团队要约定好拆分的边界。

• 拆分的粒度。微服务的拆分是一个循序渐进的过程，从大到小从粗到细，没有办法一开始就拆分成最细的粒度。

原则：交互一定要提前约定好。

途牛团队是按照下述五个重要原则约定的。

• 统一规范错误码。

• 调用方和服务方容错处理。

• 接口文档。通过工具自动生成文档，清晰明了。

• 接口技术的无关性。

• 接口的兼容性。对外兼容，接口内部不被外界感知。

交互没做好，可能出现的后果

场景一：由于双方统一规范没有执行，导致双方沟通出现问题。

场景二：参数过滤。

场景三：服务方与消费方的接口兼容问题。

容器

容器技术是微服务技术最重要的一环。微服务的概念在很早就出现了，但是直到Docker的出现解决了部署复杂，运维成本高的问题，微服务技术才更多的进入大众的视线。

如上图。在以前，部署一个服务需要一天甚至更久，部署好后需要要解决一致性问题，搭建三个服务甚至需要一周时间。

在Docker内，把服务A搭建好后，为服务A打造一个镜像复制服务B,C。在一天时间内即可部署三个服务。同时，由于三个服务是统一的镜像，天然的解决了环境一致性问题。

服务框架

服务框架的选择与选择电脑组装商户十分相似，要求有一定的口碑和靠谱的硬件提供商；可以提供一站式服务，满足多种需求；安装拆卸方便，升级替换简单快捷。

以Spring Cloud为例，它具有完整的体系，能满足微服务的所有需求，且组件服务标准。

在这个框架下，可以做到组装方便，快捷管理微服务。

注册中心特点

1.将所有的服务统一管理，把所有服务编成一个有机整体。通过组织对外提供服务。例如滴滴平台出现后，个体司机在滴滴注册，由滴滴平台进行对外业务。

2.调用不再建立传统的IP＋端口的形式，而是通过服务名进行调用。

3.便于外界发现和使用，否则十分容易被人遗忘或忽略。

重构的目的是调整程序的调用，提高软件的扩展性和维护性。

重构时要考虑三件事情。

• 前后端分离。

• 不影响业务。在业务上有两个原则代价最小原则，影响最小原则。

• 数据。之前数据的查询是在SQL内，在把产品和订单独立到服务之后，每个服务都会有自己独立的数据库。在数据迁移时，团队将SQL查询改为接口调用。但是在订单库和总库之间会存在一些问题。后来，我们选择了双向同步的方式，保证总库数据与独立库数据一致。

重构后上线业务会增多，但也带来了其他的问题。主要原因如下：

• 没有统一的规范管理

• 服务运行情况未知

• 调用关系复杂

• 服务不稳定

• 安全性

解决方法

• 上下线流程。只有经过架构师审批的服务才可上线。下线时会先把服务状态改为待下线状态，直到服务没有占用才真正的下线。

• 监控体系

• 系统图的绘制

• 促销时预估新增资源，提前做好准备

由于微服务与精益敏捷契合度十分高，团队采用了敏捷和精益的方式。

PDCA原则：

P-计划    D-执行    C-执行后的效果预期    A-循环不足之处后再从P开始优化。

这是一个通过循环往复的过程以得到持续不断的必胜。

SDCA：是一个标准化循环，只有持续转动循环，系统才能将之前获得的提升保持下去。

这两个循环相辅相成，一个不停地改善，一个把不停地改善成果坚持下来。

持续交付的意义

能持续为用户提供价值，持续收到用户反馈，持续制定更好的生产策略。

“快”的升级：DevOps理念

根据当下做出取舍

开始阶段-传统应用架构和微服务架构的取舍

发展阶段-传统应用架构和微服务架构的取舍

微服务的好处与不足

• 易扩展
  

• 技术栈不受限

• 弹性：一个服务挂掉，不会影响整个系统

不足：

Q&A

Q：请问当前的架构下，实现服务的无状态化方案是什么？

A： 我们现在开发了一个TSP框架，这个框架可以满足所有服务无状态化去实现的方案。框架本身，是通过框架协议让接口被调用。

Q：如何处理前端页面权限管控问题，避免无权限用户访问页面？

A：因为样品提供的平台是B2B，并不是所有用户都可以用。只有注册用户才能访问所有的页面，否则的话只能访问一个平台的说明页面。所以我们在最前端做了一个SQL：访问的时候除了说明页面外，访问其他所有的页面必须处于登录的状态。并且我们有一个模块，专门处理平行权限的问题，保证了分销商只能看到自己的数据。