| 编辑推荐: |
| 本文来自于网络，本文以旅游平台的系统建设为例，介绍当系统要支持一个新的业务时，如何能够快、准、好的实现，以及微服务架构的整体过程与思路。 |
|
1背景
互联网市场是一个“快鱼吃慢鱼”的市场，想要击败别人在市场占有一定份额，就要及时提升自己技术。快速响应瞬息万变的市场正是技术价值体现之一。
例如，在大的商业环境里有许多不同的业务，每个业务的技术诉求也是不同的，可能是快速上线或者高并发或者按时交付等等诉求。
技术方案是为了满足这些对技术的诉求，这也是技术的价值体现。
总结而言，技术本质上是为业务服务，无论是架构师还是底层开发，都应重视业务与技术的结合。
这里的“快”指的是一如既往的持续性的“快”，而不是断断续续的。而且随着公司规模变大，业务增多，出于成本的考虑，我们会更希望从技术上提升系统和开发人员的效率。
下面是一个在公司里经常会发生的情况。
业务人员提出一个希望能尽快上线的需求，但技术人员需要比较长的时间进行开发。这时候，产品和开发沟通后，可能会提出做一个简单的方案临时使用，后期再进行优化。
但随着时间的推移和其他客观原因，临时方案最后就变成了最终方案。在这样的场景下，极有可能会为未来埋下隐患。
在这个事例里解释了三个问题：
为什么有些系统会越来越乱。
这样的做法下并不是真正的快，只是为了快速满足业务的需求，搭建了一个存在问题的系统。
不要相信产品说的临时方案，临时最后都会变成最终方案。
2问题分析
使用微服务之前存在的问题
1.业务妥协欠下的业务债。也就是所谓的“临时方案”。
2.系统无秩序的增长。这主要体现在系统越来越大，代码愈加冗余，模块间耦合度高。上线质量差，为了解决一个BUG结果引入更多的BUG是我们当时经常遇到的情况。
3.研发人员的流动。核心研发人员离开之后，新的研发人员对之前的文档和系统都不够了解，导致让“接码侠”来维护系统，系统越来越差。
接码侠
在中大型团队中，存在一些很大很乱的系统，很少有人敢去维护，但系统对业务又十分重要。此时公司可能会招一些人维护系统，新招的人被称作“接码侠”
问题的特征
短期看来促进业务发展，长期看来阻碍业务发展。在最开始为了支持业务，系统越做越大，但发现把系统作大后对业务的支持越来越差。
具有一定普遍性。
解决问题变得心有余而力不足。一开始发现问题的时候，认为问题可以忍耐。直到无法忍耐的时候，发现解决变得十分复杂。
3微服务
微服务架构
微服务没有一个固定的标准，更多的是经验的总结。因为它不是被发明出来的，而是从现实世界中总结出来的一种趋势和模式。
下面的内容，将会介绍途牛团队的经验，告诉各位在什么时候如何去做。
微服务的特征
面向服务：把一个系统按照提供服务类型的不同，拆分成不同的服务。
单一职责：每个服务只做自己的事情。
微：每个服务下的团队小。
自治：每个微服务有自己的独立通道，不会相互打扰。
4微服务的实践
微服务拆分
在拆分之前，要问自己三个问题：
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理念
5总结
根据当下做出取舍
开始阶段-传统应用架构和微服务架构的取舍
发展阶段-传统应用架构和微服务架构的取舍
微服务的好处与不足
好处：
易扩展
技术栈不受限
弹性：一个服务挂掉，不会影响整个系统
不足：
破坏DRY原则，代码会重复
返工：建模一旦出现问题就会返工
影响组织架构
分布式复杂
网络环境制约：一但网络挂掉，系统就会瘫痪
事务一致性
协作成本：沟通成本高
需要投入
Q&A
Q：请问当前的架构下，实现服务的无状态化方案是什么？
A： 我们现在开发了一个TSP框架，这个框架可以满足所有服务无状态化去实现的方案。框架本身，是通过框架协议让接口被调用。
Q：如何处理前端页面权限管控问题，避免无权限用户访问页面？
A：因为样品提供的平台是B2B，并不是所有用户都可以用。只有注册用户才能访问所有的页面，否则的话只能访问一个平台的说明页面。所以我们在最前端做了一个SQL：访问的时候除了说明页面外，访问其他所有的页面必须处于登录的状态。并且我们有一个模块，专门处理平行权限的问题，保证了分销商只能看到自己的数据。 |
