引言
首先在使用微服务之前，需要了解关于微服务的优缺点，在使用微服务架构的时候有很多诱人的优点，但是也是存在很多的缺点。那么下面就来看一下关于微服务实现的时候需要注意的那些方面
这段时间公司新开发了一个系统，美其名曰是使用了微服务架构实际上被一堆开发人员搞成可一个“垃圾场”，整个代码的维护成本很高，开发效率比较低，没有统一的数据接口规范等等问题，感觉就像是在“屎”上建楼，不知道整个项目会被玩成什么样子敬请期待。
首先就我遇到的这个项目，也是整个使用微服务架构设计的时候需要注意的一些问题提出自己的观点。
运维难度升级
正如现在遇到的这个项目一样，对于所有服务都在同一个逻辑结构下的单体架构来说，运维人员只需要维护一套应用即可，也就是说只需要维护一个服务就可以了，现在的新的微服务架构是将一个大的服务拆分成了很多的小服务，运维人员的工作量就比较大。所以很多的运维人员都需要设计出一套属于自己的运维工具来自动化的维护这些所有的微服务。
接口一致性难以统一
对于不同的微服务来说，虽然进行了架构上的拆分，但是很多的业务逻辑是没有办法拆分，例如商品管理服务与客户信息服务，订单服务于客户信息服务等等都需要不同服务之间进行数据交互，既然需要数据交互，就不免出现通信问题和数据交互方式等问题的出现，也就是说各个服务之间必须暴露一定的接口被其他服务所使用而使用这些数据的服务也要提供新的接口给另外的服务，这就不难保证各个服务之间的数据接口的一致性问题。
分布式服务复杂性提高
微服务各自运行在独立的进程中，只能通过通信来解决数据交互的问题，设计一个微服务就要考虑到分布式带来的问题，例如网络的延迟，分布式事务，异步消息等等
那么解决了这三个问题之后就一定可以开发出好的微服务么，并不是。
在公司架构团队在整个项目的设计过程中，需要面对各种资源的不足的挑战，所以说整个的项目架构设计也是充满了各种各样的挑战。
怎么实现微服务？
首先代码未动设计先行，我现在遇到的这个项目就是一点的设计文档都没有，整个的项目都是开发人员根据自己的心情随意开发。现在我接手整个项目之后整个代码逻辑已经快被玩坏了。那么怎么去做呢
1.服务组件化
到这里就有人问什么是服务组件化，服务组件化，个人的理解就是类似于自己组装一台电脑一样，可以用联想的主机、惠普的显示器、牧马人键盘等等（这个我也不知道哪个电脑好）。当然这个是大的组件的方面，还有小的组件方面就是内存、CPU、显卡、硬盘等等。这些都是组装电脑的组件。服务组件化就是在一个系统中，某个服务可以在不影响其他服务的情况下进行无缝的衔接，也就是说可以不受限制的更换电脑组件。在微服务架构中体现在了服务的切分一定要业务互不影响，但可以相互调用。
2.按照需求分布开发团队
现在接手的这个项目，属于二三十个人花了一个月时间搞出来的微服务架构（听着就让人想笑）。微服务对于业务拆分正确的话一个团队最多需要三四个人足够开发维护一个服务。使用了二三十个人，开发出来单体不像单体，前后端分离不像前后端分离的四不像。没有统一的数据接口，需要调用新服务就需要定义新的接口。所以说整个的开发都是乱套的。那么怎么分布这些开发人员呢。首先，根据业务进行划分，例如订单处理、商品管理、用户管理等等。设计出一个优秀的开发计划。每个需求按照技术栈进行分工，业务需求按照业务分工处理。
3.服务之间调用
之前也提到过了，分布式微服务设计过程中需要解决的两个问题就是在通信和数据传递上。在通信方面有使用RPC调用的，从进程内转移到了进程间。而这样的方式对于数据的传递并不占优势。所以在微服务中使用了RabbitMQ、RocketMQ等中间件技术和Http RestFul两种方式。这里有兴趣的可以研究一下SOA和微服务。
4.服务治理
既然出现了很多的微服务那么对于这些微服务的管理就成了重点，先来吐槽一下我项目上的这个伪微服务。将一个“四不像”，整个当做了一个微服务注册到了Eureka上，那么服务治理和服务注册中心到底有什么用呢？简单的说就是管理谁调用谁。需要发布一个新服务就需要遵守约定的通信方式，数据交换方式等等，然后将这个服务注册到服务注册中心，由服务治理统一管理。当然这个只是一个最简单的理解，现在提倡的是建立高可用的服务注册中心。
5.容错机制
对于一个高可用微服务架构来说就需要由一定的容错机制，也就是说某个服务出现问题不会影响到其他服务正常的使用。服务有正常的熔断机制，不会出现某个服务宕机影响整个微服务。我们希望在每个服务中都有对应的心跳检测机制。对于服务的生命状态进行监控。这也是开发微服务架构所需要注意的一点。
总结
对于微服务架构设计之后的博客中还会有更新，这篇文章就是对于公司架构组的一点点的吐槽。
