华为云微服务引擎的前世今生
华为从12年开始在很多创新项目里应用微服务技术，在14年随着微服务框架技术越来越成熟，工具越来越完善，公司各个产品线开始基于微服务框架做云化产品，16年的时候公司为了更好的进行能力共享，决策把散落在公司各个产品线的一些与微服务相关的工具、平台、框架和团队统一整合成华为公司级 PaaS 平台重要组成的一部分，专门负责微服务平台的交付和技术演进，统一支撑整个华为公司产品微服务化转型，在17年随着云BU的成立，公司就把这个内部微服务能力以云服务的形式放到华为云上开放出来，这样可以让业界更多的企业和开发者能更方便的使用微服务技术，少走弯路。截止当前华为无线、云核心网、消费者云等基于此微服务框架都已完成云化及商用。
微服务在业界的使用状况
上图是著名的开源软件Nginx，在官网面向全球开发者做的一次关于微服务使用情况的调研，从这份数据可以看到，目前接近70%的开发者正在使用或试用微服务技术，其中接近30%的企业已经在生产环境中使用微服务，也就是说微服务早已经过了概念炒作阶段，已经是实实在在地进入到了成熟商用阶段。其实，从华为内部看，微服务解决方案目前已广泛应用于华为消费者云、无线产品线5G、企业智能EI、内部流程IT、云核大视频等等核心产品领域，是公司业务全面云化的基座。
为什么要用微服务
在讲为什么要用微服务前，先看看企业的原始业务诉求有哪些？
随着云化和互联网技术的发展，企业的it部门从原来的成本中心转变成生产中心，如何将客户需求和软件价值更快的交付到客户手中成为企业的核心竞争力之一，以前是大鱼吃小鱼，现在是快鱼吃慢鱼。
现代软件应用的领域越来越广，无论是工作，生活还是娱乐，这些应用（特别是消费类应用）有些会有明显的流量波峰波谷，例如游戏一般在工作日和白天玩的少，而在休息日和晚上玩的多，还有一些应用无法预期流量，可能大部分时间流量一直稳定，而一个意外事件的发生就会导致流量指数级增长，无论是哪一种场景，都要求应用架构能具备更好的弹性能力来保证业务的可用性。
经过这么一波互联网技术洗礼之后，行业边界正变得越来越模糊，很多企业特别是传统行业都希望通过业务创新获取新的增长点，而我们都知道业务创新九死一生，那么低成本的快速试错是迫切追求的，怎么样低成本，其实从IT部门视角来看，如果能基于团队已有的技能，重用企业已有的技术资产（比如投资了很贵的技术平台软件），这就是节省成本。
另外一点，不同行业不同领域都有不同技术栈，举个对程序员最能理解的例子，开发语言没有绝对的好坏，例如java，c++，python，go等都有它最适合的场景，大多企业的技术决策者都希望能用最合适的技术去匹配业务，所以在选择能支撑未来业务持续发展的基础性框架和平台产品时，对技术开放性的考量也是至关重要的。
从很多客户（包括华为内部的业务团队，以及外部的合作伙伴和各种类型的企业客户），还反馈了这样一些诉求，例如：高可用性、容错性、可管理性、可替代性、可测试性、组织扩张、架构弹性...等等。其实从这些反馈不难看出，业界对微服务的诉求不仅仅是需要某个单点问题或一个工具套件，而更多的是希望通过微服务这种新的研发理念来改变整个研发活动的方方面面，包括技术、组织和流程的变革。
从最终的业务视角来看，我们认为微服务的价值可以简单总结为三个词，即：
更快、更稳、更经济
微服务的本质是化繁为简，分而治之，从而加快企业创新。
-
更快：是指业务上线的速度，使用微服务能把业务上线周期从年降到月、周，甚至是随时上线；
-
更稳：是指系统可用性，基于微服务构建的系统能把系统SLA从3个9提升到4个9、5个9，甚至永不断服；
-
更经济：是指业务的资源成本，基于微服务更细粒度的弹性，能实现业务规模扩张与资源支出的最佳平衡。
借用赤壁之战这个耳熟能详的典故，可以更形象的理解微服务与传统单体架构的区别：如果一千多年以前曹操不把自己的百万大军用铁链连成一个像单体应用一样的整体，而是让每条船像微服务一样，能独立指挥独立作战，也许就不会被孙刘的一把火烧的这么狼狈。
微服务带来哪些新的挑战
任何事务都有两面性，微服务也不例外。从我们经历的这么多实践项目来看，微服务主要带来的挑战如下：
如何基于微服务架构高效开发和上线
微服务本身也属于分布式技术的一种，分布式系统对编程的门槛其实是很高的，传统的单体应用因为是单进程，组件A与组件B的进程内调用只需使用编程语言的语法，一行简单的代码就能搞定，根本就不用考虑服务发现、负载均衡、限流容错等等技术，但是在微服务系统里，服务A调服务B时，首先要找到服务B在哪里，有可能服务A和B部署在同一个节点上，也有可能服务A部署在深圳，而服务B部署在北京的一个机房，所以服务的注册发现是微服务应用开发人员需要解决的第一个问题。
找到服务B以后，有可能服务B是多实例部署，这时候又需要在多个服务实例中找一个最合适的实例来处理请求，那么这就涉及到第二个问题：负载均衡，后面还有服务调用失败了要考虑服务容错，还有服务限流、服务降级、分布式事务等等诸多复杂的分布式技术问题，如果我们把这些问题都留给业务开发人员，显然业务开发是快不起来的，这就是微服务化之后面临的第一个问题：如何基于微服务架构高效开发和上线。
如何在不可预期的流量下如何保证业务的高可靠运行
从一个单体应用拆分成多个独立运行的微服务应用，从理论上来说，系统的故障点是增多的，用户请求的每一跳都有可能出错，特别是在资源受限的大规模流量冲击下，这又引入微服务化后的第二个问题：如何在不可预期的流量下如何保证业务的高可靠运行。
在复杂的微服务系统中如何实现问题快速定位与恢复
而微服务系统的运维是个更显而易见的问题，一般传统的单体应用问题定位过程是这样的：首先登录到出故障的应用节点，然后找到应用的相关日志文件，导出到本地后就可以使用各种文本工具进行日志分析和问题定位，整个过程很简单，人工就能搞定。
但在微服务系统中，特别是在动辄上百个微服务和实例部署的场景下，一个业务请求很可能跨越了多个微服务多个实例多个节点，别说定位问题，就是先搞定问题定界都很难，这时候如果没有一个自动化的工具或平台来支撑，靠人力是不可能完成的任务。
传统架构下的遗留系统如何向微服务架构低成本迁移
最后是一个非常现实的问题，特别是在传统企业里面，都会有一些遗留的资产或运行中的业务系统，不可能把这些都推倒重来，不仅成本太高，而且业务风险也大。如何将传统架构下的遗留系统低成本的向微服务架构迁移也是微服务解决方案需要系统考虑的。
同时真正要实施好微服务，对企业的组织架构、业务流程以及人的素质模型都提出了新的要求，所以向微服务转型是一个企业系统性的变革活动。
欲知后事如何，且听下回分解...
- End -
