微服务的理想与现实

互联网初期， 2G还是个时髦词儿，人们的需求也很朴实，一个静态网站告诉大家我是谁、一个留言板让大家能够与我联系，就能满足信息传播和互相交流的需要。于是码农们给我们提供了这样一套解决方案：
界面+业务处理+数据处理，通过一个zip包就可完成所有的事情，这也就是服务架构的
单体架构时代。
图片为作者原创随着3G的普及，越来越多的人们可以通过PC上网了，此时BBS、门户咨询网站的出现开始吸引着大量观众。当漂亮的交互更能抓人眼球、有趣的信息瞬间引爆千万用户在线围观时，“并发“问题产生了，于是码农们加班奋战，将系统分为前端和后端，通过拆分出可复用的中间件，来提升业务处理能力、解决并发问题，这便是
分层架构时代的到来。
图片为作者原创后来，互联网进入微博时代，几乎网民都有Blog，打开手机就刷weibo。而此时的分层架构面对更复杂服务要求时，在应用扩展、服务调用、扩容等方面都越发桎梏，于是服务架构走进了面向服务的架构（SOA）时代。SOA网上说的很多，这里列举几个关键词：
中心化的服务治理， ESB（企业服务总线）中心化、服务之间通过精确定义的接口进行通讯、耦合度更低、扩展性更高、维护成本较高。
图片为作者原创又过了几年，电商掀起了各个时节的线上大促活动，与之伴随而来的还有持续交付、灰度发布、服务限流、容错保护、链路跟踪、日志监控、弹性伸缩等等一大串需求，也还有程序员日益见秃的头顶和度数越来越深的眼镜。当运维压力已经赶不上业务的快速发展时，
微服务时代来临。可以这样理解，微服务架构也是SOA架构分布式化的一种实现方式。它的优势在于小而治之、去中心化，但与之对应的问题是，你要管理越来越多的微服务。而如何进行微服务拆分和服务治理，是十分考验能力的试金石。纵观前后，服务架构历次的迭代更新，都是围绕着用户如何节约成本和提升效率，来解决不断出现的新问题，
微服务就是服务架构演进史的产物之一。
图片为作者原创微服务最流行的定义是由 Martin Fowler 与 James Lewis 于 2014 年共同提出。引用老爷子们的说法：
根据InfoQ发布的2019架构和设计领域趋势报告显示，微服务架构已经走过了盲目追捧阶段，开始逐渐走向成熟，走向切实可落地阶段。
图片来源：InfoQ发布的2019架构和设计领域趋势报告在我们选择之前，先来看看有什么能够选的？
1、微服务框架的分类目前市场上已经出现的微服务框架非常多，他们各有所长。常见的微服务框架都有哪些呢?如果从常见微服务框架形式分类来看，目前主要分为4类。如果按照目前的主流生态体系来看，目前有三大生态体系：这里特提供了官方地址供大家学习，本文不再详细展开讨论，每一个家族都需要熬夜掉一把头发，潜心实践和学习才能掌握。总而言之，微服务的核心是服务治理，而服务治理就需要好的微服务框架，要不然微服务化可能是灾难！但做为用户，选择适合自己实际情况的才是最好的。
2、选择适合自己的微服务框架那么我们该如何选择微服务框架呢？依赖于业务特点和技术能力。先选定方向，再研究技术细节。下面关于方向选择的思路供各位参考：如果你的业务模块与服务治理是整合在一起的，依托特定开发语言和开发框架，通过配置来调整规则和策略，依赖业务上线对服务治理进行功能升级，那么你可能比较适合集成方式进行服务治理。你可以在Spring Cloud、Dubbo生态中去选择合适自己的方式。如果你的业务模块与服务治理是分开的，与开发语言无关、与开发框架无关，通过动态调整来配置运行时各种规则和策略，服务治理功能升级独立于业务模块，那么你可能比较适合服务网格的方式进行服务治理。你可以在云原生家族中去选择合适自己的方式，比如尝试下Istio。
3、什么时候引入微服务？微服务不是万能的，换句话说，微服务未见得适合于你。
1）天时在业务运行初期，如果你是单业务系统架构，如果业务量不大且复杂性不高，如果你追求快速响应、开拓服务、节省成本、提高效率，那么你可能真的用不着微服务。比如你如果只是要用CMS做一套公司网站，那真的可能不用微服务这把牛刀。当随着你的业务进入扩展期，你的系统架构开始走向面向服务架构，业务不断扩大，业务系统复杂性不断提高，但效率在不断下降，那么这个时候你可以开始考虑业务拆分、使用微服务了。2）地利如果要进行微服务改造，还需要具备一定的资源条件，如物理机资源、网络资源。举个例子：假设一个电商平台，现状如图。如果业务框架不那么复杂则可考虑不用微服务架构。而如果需要进行微服务改造，那么至少需要准备规划好如下资源：
3）人和如果要享受微服务带来的优势，就需要接受微服务带来的挑战。比如：总之，使用微服务也是需要天时地利人和的，使用的过程也不要一蹴而就，服务治理是巨大的挑战。你的业务适合微服务吗？我收集整理了几个最简单的问题以供快速自测：
简单来说4步走：
其实每一步都有可能会有“坑”，这里面都是学问，都可独立成章。因此，本文不详细展开，以后再写相关内容文章详谈。但是，Demo可以快速帮我们一探究竟，这里我选择了京东智联云的微服务平台来做体验。
为啥是云上公有云产品？因为微服务的体系太复杂庞大了，如果你自建，1个人搞不定1个团队的工作内容。还因为在“云”上是托管服务，少运维，所见即所得组件多，开源、多可用区、上手够简单够快、学习和使用成本低呀。简单总结下我的学习路径：1、体验“云”上高可用注册中心如果您已有成熟的微服务项目，目前正在上云过程中，希望享受 “云” 带来的注册中心多可用区部署、最大程度的保证集群高可用的能力。那么可以直接使用微服务平台的命名空间注册中心功能。目前JDSF支持的微服务框架包含：SpringCloud、Dubbo、JSF。使用大致步骤如下：
入门示例参见：

https://
distributed-service-framework/basic-example
https://
distributed-service-framework/basic-example
https://
distributed-service-framework/demo-deploy-k8s
https://
distributed-service开发云主机域名-framework/gw_vpc
怎么样，微服务看上去是不是又没有那么抽象、那么难、那么抓狂了呢？！更多内容下次再分解。

欢迎点击“
京东智联云
”了解更多精彩内容！

相关推荐: 企业为何要将ERP系统迁移至云端？

我们都知道，ERP是企业的关键业务系统，包含大开发云主机域名量与业务相关的数据，因此很多企业迟迟不愿意上云，甚至干脆拒绝上云。但是，ERP迁云却是大势所趋，如果不上云，则变成企业IT管理效率低下，还有可能让企业业务失去市场竞争优势。所以，把ERP迁移到云端，成…