Cai Cai brother, last hear you talk about the micro-services and SOA, understand a lot of sense
It seems interview were using it
Oh, but the interviewer asked me microService What are the advantages and disadvantages ...
It seems to have to give you a detailed talk about micro service
Micro Services (Microservices Architecture) is an architectural style, a large and complex software applications by one or more micro-service. Each micro service system may be independently deployed between the respective micro-services are loosely coupled. Each micro serve only to focus on and complete a task well done the task. In all cases, each serving represents a small micro-business capabilities.
Micro service is based on the program can be run independently of the specific business areas border demarcation out, and can be deployed independently, can scale based on volume of business, changes will not affect other programs running. To put it simply: Micro Services is a certain boundary has its own context service architecture concept.
I'll give you a little brother Cai Cai talk about it, to see how I am talking about
Okay, listen.
1. Micro services more easily extended, it is substantially independent. Internet applications deal with large concurrent systems can be done automatically resilience to deal with.
2. Each micro services by different teams, using different technology stack development, just follow the protocol agreed to modify each micro services will not affect the normal operation of other services.
3. Architecture abandoned the idea of micro-services architecture style of the center, further reducing the coupling between systems, whether it is in the development stage or deployment phase is independent.
4. Micro service due to the rapid development and delivery, so the receiving capacity of the new technology is much higher than other systems, such as: a traditional system services can be quickly modified micro-cloud, quickly adopt k8s deployment.
5. Each micro-services follow the same protocol standards, so the communication between the team and then can reduce a lot of unnecessary trouble.
The advantages of micro-services generally can be summarized as the above points
Said, well, ah, but micro service has many disadvantages, I do not know you know
Micro service is good, but not perfect.
The number of services
微服务从字面意思就可以知道强调服务的“微”，但是这个微的粒度，多数人都理解错误，有人说：微到不能再微是微服务划分的理念。我不这样认为，微服务的领域边界是根据具体业务来划分，过度的划分，只会导致微服务的数量急剧增加，团队的效率急剧下降。有的团队只有5~6个人，然而却拆分出几十个微服务系统，平均每个人要维护5~10个微服务，这样做给团队带来的只有负面效应。无论是开发，测试，还是运维都需要在多个微服务之间不停的切换。
当微服务上线之后，几十个微服务需要启动几十个进程，在加入了负载均衡与消息中间件后，进程的数量还会持续添加。运维与编排全部这些服务是个“令人望而却步的任务”。
当微服务粒度过细，会造成代码复用度进一步降低，一些通用的代码你可能需要在多个服务间进行copy，如果某段代码有问题，你同时需要修改多个服务代码，当然同种语言可以使用代码共享库来解决，但是在多语言的情况下是行不通的。
事务管理
无论微服务怎么样划分边界，业务上无法避免在多个服务间的事务性操作。最简单的下单场景：很多情况下订单和用户资产是不同的微服务，当用户支付成功，扣除用户资产和更改订单状态（还有减少商品库存）应该是一个原子性操作，如果在以前的单体应用公用一个数据库的情况下，用DB的事务很容易实现原子性操作，但是在微服务环境下，实现事务有一定的难度，尤其是当服务间采用异步操作的时候，这就很复杂了，这要求我们得“管理好相关联的ID以及分布式事务，将各种动作绑定在一起”。
服务关系
服务划分过细，单个服务的复杂度确实下降了，但整个系统的复杂度却上升了，因为微服务将系统内的复杂度转移为系统间的复杂度了。从理论的角度来计算，n 个服务的复杂度是n×(n-1)/2，整体系统的复杂度是随着微服务数量的增加呈指数级增加的。下图形象了说明了整体复杂度：
调用链太长
服务间的通信都采用标准的Http或者Rpc协议，只要是通过网络的调用，就会耗费资源，就会花费更多的执行时间。如果一个请求需要顺序的调用N层服务，那么这个请求所花费的时间是不容忽视的，这在大并发的系统中是致命的性能损耗存在，系统的吞吐量会大幅下降。虽然增加硬件在一定程度上会缓解这种问题，但是却在根本上解决不了问题，而且在成本上会大幅度上升。
另外，服务的调用链太长，定位系统问题很难。一个业务请求会经过N个微服务，任何一个服务有问题，都有可能会导致业务失败。由于调用的微服务过多，而且异常有扩散的属性，快速定位服务问题对于开发以及测试来说，是一件很复杂并且很难的事情。如下图所示：
如果服务C发生故障，开发定位问题的时候需要从服务A开始追踪，然后追踪服务B，然后是服务C，如果调用链更长的话，还需要继续追踪。当定位到问题之后，可能已经过去了几个小时，这在一些敏感的系统中是不允许的。如果服务的复杂性如下图所示，该怎么办呢？
微服务的架构设计中，做好服务的追踪是很重要的
自动化支撑
如果没有相应的自动化系统进行支撑，都是靠人工去操作，那么微服务不但达不到快速交付的目的，甚至还不如一个大而全的系统效率高。
1. 没有自动化测试支撑，每次测试时需要测试大量接口。
2. 没有自动化部署支撑，每次部署 6 ~ 7 个服务，几十台机器，运维人员敲 shell 命令逐台部署，手都要敲麻。
3. 没有自动化监控，每次故障定位都需要人工查几十台机器几百个微服务的各种状态和各种日志文件。
当服务的数量到达一定程度，假如如上图所示，服务的治理难度就会被提上日程。当微服务的种类和数量越来越多，如果没有微服务的治理系统去支撑，微服务的优势就会变为劣势，包括每个服务的注册和发现，每个服务的部署，每个服务的隔离，甚至每个服务的路由。
如果还是人工去干预这些，最终服务系统将会变的一片混乱，微服务推重的快速交付，横向扩展等特性也将变的复杂。
微服务的重点不止在边界的划分，还有服务的治理。就像容器一样，容器很重要，但是容器编排同样重要。
哎呀，微服务原来有这么多缺点，我再考虑要不要学呢？
总体来说，在适合微服务的场景下，还是推荐使用微服务架构，在交付过程中，优势还是要大于劣势的
