一、经典微服务架构的特点以及问题
经典的微服务架构一般包含两个部分：API网关，一组微服务。API网关是唯一的请求入口，它还要负责负载均衡，路由编排，失效切换等工作。
经典的微服务架构图(来源网络):
关于经典微服务架构的文章很多，这里重点想分享一些我们实践经典微服务架构的一些问题：
“笨重”的API网关，由于它要负责各种核心功能，不能灵活扩展，比如负载均衡策略，也许每个微服务类型需求都不一样，它很难灵活变更;随着对接的微服务越来越多，每个API网关也集成大量的功能。
API网关自身需要高可用保证，经典架构并不提供，随着后端接的微服务越来越多，也会造成很多稳定性问题，它与微服务也需要两套运维办法，给运维带来额外成本。
服务注册与发现还是传统模式，不能级联代理，长连接也有限制，不能很好解决跨大网段，跨机房，跨IDC中心的问题。
心跳机制比较单一，只是从连接层面考虑，没有上下文以及服务本身的监控，需要依赖第三方实现。
失效切换机制单一，只能是联通性检查，对业务异常无感知，意味着不能根据业务异常切换。
没有自动高效的重试机制，需要考虑对API网关的改造。
几乎没有隔离机制，需要采用第三方技术解决。
微服务实现没有统一的技术栈支持，还处于原则规定阶段。
服务编排依靠人工，没有动态编排能力。
整体看来，经典微服务架构还不够“聪明和智能”，于是我们设计并着手研发新一代微服务计算平台，希望能够让其充分发挥微服务架构的优势和特性。
二、微服务计算平台的设计思想与抽象模型
1
“微智能”的设计思想
“微智能”这个概念起源于智能家居，是目前智能硬件领域的一股创新思想。在提到“智能”这个词，通常是相对人而言，智能家居通过“智”的体现，更好的服务人的生活。于是，我们就思考是否系统或者服务也能体现“智”，如果与微服务相结合，让其更加“聪明”的工作?
先来看看微智能的设计思想：
1)自动发现： 即真实的反映现实世界，尽可能利用“自动化”手段捕获现实情况并提取有效”信息”。微服务实际上对原有的单体系统或”重”服务进行了拆分，意味着服务种类以及服务实例个数会成倍增加，依靠人工整理或编排的手段变得笨重滞后。自动发现实现了微服务生命周期管理初始环节的自动化。
2)自我维护： 即形成“闭环”反馈回路，将“输入”或“中间”或“结果”信息再反馈到系统中，合并成新的“输入”或“中间”或“结果”信息。真实世界的信息变化很快，为了尽量趋近真实，需要不停的迭代。微服务架构除了更多的服务实例个数(规模增长)，也意味着更加“多变复杂”的服务更迭(变更频率增长)，自我维护实现了微服务生命周期管理更迭的自动化。
3)自动适应(适配)： 自动适应拓展了自动发现+自我维护的思想外延，是“智”的体现。根据自动发现的信息适配相应的处理(初次适应);根据自我维护的反馈，不断调整(迭代适应)。比如服务降级的阀值，其实不同时间不同资源使用情况下这个阀值是动态变化的，在数百服务实例的级别都已无法依靠人工来进行调整，而需要每个服务实例依据上下文的环境以及历史状态的分析自主的调节。
所以微智能设计思想的三个核心原则正是构建“智”的微服务计算平台的基础指导思想。
2
“拟社会化”的分布式设计
有了微智能的思想，我们还需要重新认识“服务”。什么是微服务，社群里有很多文章都分享了相关的内容。我们理解服务的“微”体现在：
细粒度的服务能力： 某个服务实例只完成一种或某几种业务，或说只具备某一种或几种能力。