ServiceComb开源前，在公司内部已经存在了两年的时间，在这段时间里，同时还有在用其它的产品。华为内部使用的产品非常多，根据华为公司的特点来看，它的应用大多都是企业级的应用，很少有互联网应用。所以我们一直会面对着各种各样企业级应用的需求。公司内部各种产品的要求也是不同的，比如我们有IOT类的应用、商城类的应用等等。但我们在坚守着微服务架构原则的基础上，也在尽量满足公司各种各样产品苛刻的要求。
企业IT技术应用曲线
2014年被很多人认为是企业上云的元年。从这一年开始，很多企业把应用搬到云上。
2014年几乎企业应用都没有考虑的Docker。到了2015年开始，很多大型企业就已经把Docker列入了采购或使用计划里面。
微服务在2016年成为仅次于物联网和认知计算的第三热门技术。近几年有越来越多的大型企业开始使用微服务，渐渐地把应用重构成微服务架构。
传统企业应用开发模式
传统企业应用的开发模式的特点是统一制定产品发布计划，然后把产品发布分成几个小的组件，每个人负责一个小组件进行开发。开发完统一时间进行集成，最后打包发布成一个复杂的应用。
这个过程技术实现单一，需要想办法用一种技术解决所有问题。发布时只能按大颗粒系统发布版本，响应周期会比较长（小特性版本3-6个月，每年1个大版本）。无法做到永远在线，大版本升级时，要停机中断服务。
上图是微服务架构下应用的构建和发布流程。它最大的特点就是把大的应用拆成若干小的部分，每一个微服务所有的发布计划和构建技术都是非常灵活的，每一个服务各自制定自己的发布计划，用最合适的技术进行实现，我们整个系统的上线周期和更新周期会比较快。
Speed & Safety
“快”是现在所有企业和用户实施微服务架构的第一原因。但是“快”的同时如果做不好防护，会变得非常危险。尤其是现在的企业应用，它和互联网应用有一些不同的地方，它的要求就是必须要安全。中断的时间可能会出现一些问题，所以安全一定是在微服务架构之后的重点强调的第二点。
面临的问题
我们最初在做微服务的时候并没有在企业应用中应用微服务架构的经验，这时微服务的概念更多的是来源于互联网。我们要思考的是来自互联网的应用业务形式和企业应用有何不同。
在一个大型的企业应用里，通常情况下它的应用是由ISV来进行开发的。站在企业的角度来说，如何做到不同ISV的应用互联互通统一管理，是我们在开发时需要考虑的一个非常好的问题，同时也是一个急需解决的问题。
微服务主要是让业务变得更快，反映到开发上，就是让开发足够快。那么怎样才能加快微服务的开发？
使用微服务会出现很多问题，性能问题就是其中之一。原来的单体应用都是方法间的调用，当然很快。但它变成微服务以后，微服务之间的调用一定会影响到性能。微服务化后如何保证性能，把影响降低到最小？
在企业应用中强调统一的管理，如何进行统一的路由控制也是我们面临的一个问题。
企业应用和集成
API First：
面向契约而不是逻辑；
解耦服务提供者和消费者的开发顺序；
契约定义为语言中立；
规范化系统接口，让实现与文档的同步成为必须；
通过工具简化整个过程。
增速微服务开发---降低学习门槛
降低学习门槛也是增速微服务开发中非常重要的一点。在我们的框架中是支持SpringMVC和JAXRS的方式去写微服务。
SpringMVC：
JAXRS：
性能保证
我们把通信变成了全异步的方式，性能方面提升了很多，具有标准、开放、协议健壮性。开发框架的性能在于细节，而不仅仅是协议。
更细致的服务路由管控
统一的路由策略管控；缓存以提升性能；支持pull/push两种模式监控实例变化；实例动态扩容，海量的长连接或者短连接；支持灰度发布、服务分组等高级管理特性。
还远远不止这些...
之前在我们公司的项目中，微服务不仅仅是一个SDK的事情。要想让应用开发和业务上线更快，需要管理的是微服务开发生命周期和微服务运维生命周期。
在内部构建微服务的时候，我们在每一个环节把微服务的开发和运维完全打开，在每一个环节进行优化。
从软件到服务
我们公司内部在做微服务这件事的时候，考虑到了很多方面。现在我们把这些经验做到了云上，做成了一个服务。如果你感兴趣的话可以去看一看我们做的华为云微服务引擎：http://www.huaweicloud.com/product/cse.html
有不同的意见也欢迎来和我们进行讨论，参与到社区工作中：
ServiceComb官网：
http://servicecomb.io/cn/
ServiceCombGithub：
https://github.com/ServiceComb
微服务引擎交流论坛：
http://forum.huaweicloud.com/forum.php?mod=forumdisplay&fid=622。
我今天的分享就到这里，谢谢大家！
