认识达内从这里开始

微服务架构开发随着互联网的不断发展而被越来越多的程序员掌握，今天我们就通过案例分析来简单了解一下，微服务架构应用都有哪些方法。

1、一组小的服务一组“小”的服务，这个小其实是相对而言的，原来的单体服务都是把所有的业务大而全的打包在一个单体结构中，而微服务将这些单体结构进行拆分，形成一个一个独立的服务，这个小是相对原来大而全的结构而言。很多同学会纠结“小”这个点，那么要多小的程度才为之“小”，因为这个小并没有特别和明确的规定，所有这也引申出来现在很多DDD领域驱动设计来指引微服务的拆分，基本上一个微服务能让一个开发人员能独立的理解，就可以称为一个微服务，具体有多少行代码不是关键。

2、独立的进程微服务是运行在独立的进程当中，例如Java程序部署在Tomcat的容器中，也可以将Tomcat部署在Docker容器中，因为容器本身也是一种进程，所以微服务可以以进程的方式去扩展。使用容器进行部署，使得定义，部署与运行一个微服务变的更加简单，由于微服务粒度比传统的SOA服务更小，它对Web应用服务器的要求也变成更加的轻量级。

3、轻量级的通讯微服务主张使用轻量级去构建通讯机制，我认为是使用基于HTTP协议的API资源，一般是RESTfulAPI。不过现在正式投入生产的应用中，微服务之间的通讯绝不止于RESTful，虽然HTTP协议相对来说较为简单，但它在传输的性能和可靠性也存在比较大的局限，特别是JSON在序列化也较弱。所以在微服务内部通讯会使用更多的RPC框架，例如Netty，gRPC，阿里的dubbo协议等等，甚至还可以使用消息中间件来完成通讯传输。究竟我们的服务应该选择RPC还是RESTful，在后面的章节会进行讨论。

4、基于业务能力构建文中强调了服务的规划和划分，是基于业务进行构建，这一点非常的重要，是业务而非技术驱动微服务的设计，这一个观点从而也推动了领域驱动设计(DDD)的发展，越来越多的人尝试将领域驱动设计引入微服务架构的设计中。例如：在电商的系统中，我们划分服务更多考虑的是业务，例如：用户服务，商品服务，订单服务等等，这个在后面划分服务的章节将会再进行讨论。

5、独立部署在以往的大型独体项目中，部署和发布永远是高悬头顶的达摩克利斯之剑，某一个模块的错误都可能让整个系统崩塌。但是微服务的一个关键原则是：每一个服务都是系统的组件，均可以独立的进行部署，团队之间是不需要特别的进行协调，当我们开发和部署一个服务时，我们只需要确保测试和部署好一个服务，如果真的把它搞砸了，也不会把整个系统都搞砸。当然，一个服务挂掉了不会把整个系统都搞砸，还需要建立在一个好的微服务治理上，这个问题我们在后面的章节中也会讨论。

6、小的中心化管理小的中心化管理，其实也可以称为“无集中式管理”，原来的单体服务需要整个技术团队都是独立的架构团队去进行管理，统一的架构，统一的技术栈，统计的存储。而在微服务中得益于服务的拆分，人员的拆分，所以在实施微服务将不再受限于系统的技术栈，无论是开发的语言，数据库，缓存都是可以进行自由的选择。从理论上来说，微服务是一种通过网络协议的跨平台调用，只要规定好服务的接口和服务的网络协议，服务本身的技术都是可以自由选择的。对每个系统本身来说，是小的中心化管理，但是，如果从整个微服务的系统架构来说，我们需要考虑到整个微服务的注册，发现，降级，监控，编排等等，这也衍生了我们对微服务更多的“管理中心”，例如我们会使用SpringCloud或Dubbo框架进行管理。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。