认识达内从这里开始

微服务架构开发是目前大多数软件编程开发程序员都在学习与应用的一个编程开发技术，而本文我们就通过案例分析来了解一下，微服务架构开发都有哪些用法。

微服务架构

我们已经意识到：技术架构受公司业务和组织架构影响。作为从单体架构过来的人，起初我是拒绝的，或者说担心我们的业务被拆分后出现不稳定状况。但是随着业务突然扩展，业务不断细分，敏捷开发和配套的技术方案迫在眉睫。

技术选型

先根据总体业务规划，我们先做了初步的技术架构规划，然后确定选型思路：

不绑定到特定的框架，跨语言

服务好是Restful风格(风格极简，且是主流标准)

足够简单，容易落地，将来能扩展

稳定性强

Dubbo、DubboX：优势在于全栈、服务治理的支持性强，是阿里巴巴开源且经过阿里巴巴实践的产品，中文文档很多，社区活跃。但选型时停止维护，跨语言难度较大

SpringCloud：是Spring旗下的子项目，社区足够强大，架构本身简单方便，几乎零配置。基于RESTfulAPI，跨语言。但当时SpringCloud实践较少，且性能和RPC相比不占优势

Motan：是微博平台微服务框架，承载了微博平台千亿次调用业务。优势在于性能，且实现模块化、结构简单、易于使用、跨语言，但对于复杂的业务支持不够好

Thrift、gRPC：并不能算作微服务框架，自身并不包括服务发现等必要特性

架构替换

经过短期探索调试后准备开始试水，暂时不敢动主流业务，我们就从对外提供的一些接口服务和部分独立系统开始下手，这个阶段我们尝到了甜头，但紧随其后就是各种填坑，质疑不断，不过后我们还是坚持下来。

构建容器云支撑

微服务初步改造后，给我们带来了一些额外困扰：

微服务过多，服务治理成本高，不利于系统维护。

分布式系统开发的技术成本高(容错、分布式事务等)，对团队挑战大。

显然，我们不能通过jar包启动的方式去维护大批量微服务，而且这些服务部署在一起还相互影响。

容器云+微服务

在刚引入微服务后不久，我们并没有急于替换所有业务，而是把基础运维工作做好，随后我们引入了Docker。Docker给我们带来了：

迭代效率提升支撑：Docker用户发布软件的频率平均快了7倍

环境可移植：Docker是一个代码运输集装箱系统，它使得通过Linux的软件开发和交付变得很容易

更快且更小：充分利用服务器资源，一台虚机可以跑几十个容器

标准统一：可实现环境甚至架构的复制性

光有Docker还不够，我们发现引入Docker容器后，虽然解决了一些问题，但是还不够。我们运维起来太麻烦，各种Docker命令还有脚本，甚至我们都不知道我们到底有多少服务，它们健康状态、资源占用怎么样，当业务量激增难道我们永远都是被动且手动的去做服务伸缩么?

当我们从大量运维工作中解放出来后，我们发现，小团队也可以做大事情：

小团队作战，敏捷开发方式，替换其他业务

解决方案打包，一键部署

抽出人手构建我们同等重要的DPaaS平台

部分业务变化快的模块快速优化甚至重构

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。