- 小白不太明白 如果要说理解 我只能简单类比于服务器的负载均衡
- 希望 V 站的老师们能各抒己见 谈谈自己的认知咯
- 纯粹是交流 以和为贵咯 嘻嘻 ：）可爱
This topic created in 2787 days ago, the information mentioned may be changed or developed.
 |
boris1993Mar 30, 2019 via Android
1
今天刚听前辈谈了下微服务，说下我的理解
拿商城举例，传统架构是把商城作为一个整体看待，简单来讲就是一个 war 包部署进一个 tomcat 示例 微服务则是把应用按照功能，拆分成较小的，可以独立运行的模块，比如拆分成用户、登录、下单、搜索等几部分，模块之间用 HTTP 或 RPC 协议通信 |
 |
ferockMar 30, 2019 via iPhone
2
各种名词只是新瓶装旧酒。有一些公司 boss 喜欢搞的自己很高大上，于是就喜欢吹嘘这些名词，举个例子…生态化反…
囧 rz … |
 |
hilbertzMar 30, 2019
3
原来 1 个人干的活，变成 10 个人干的活
|
 |
4
不同人看微服务都不一样吧。在我看来，微服务以服务为基础单元，配以 rpc 为核心的一系列中间件进行开发的一种方式。
主要是传统的单体架构应用在面对用户增长时难以进行横向扩容，应用局部存在性能问题，却只能扩容整体。 单体架构在进行开发新功能时也会造成整体代码的腐化，包括难以测试，难以维护。 对于小公司来说微不微服务没啥必要，能用最重要。 |
3 |
akiraMar 30, 2019
5
面向对象会吧 类比一个个对象更合适
|
 |
just1Mar 30, 2019
6
把一体机变成可以自由装配的台式机
|
 |
a123321456bMar 30, 2019 via Android
7
性能不够怎么办 加服务器配置
还不够怎么办 每个服务器少做点事 几个服务器拼起来组成整个系统 |
 |
LuckyrayMar 30, 2019 via iPhone
8
简单说就是模块化
|
 |
no13busMar 30, 2019
10
首先你需要区分单体服务，微服务，soa 服务这几个
|
 |
rogwanMar 30, 2019 via Android
11
用企业部门打比方，传统组织机构是研发 销售 行政部这样，微服务是各种 CXO。
|
 |
13
@lynskylate 哈哈 的确是 如果这么理解 前后端的分离 算是模块化么
|
 |
lhx2008Mar 30, 2019 via Android
16
细粒度服务（不是一个公司一个大 jar 包），自动化流程（测试，发布，扩展等），完整的基础设施（配置中心，路由，熔断器，服务治理，链路监控，网关），轻量级服务通信（ rpc，restful ），和服务数量相对应的开发人员（公司就几个人拆服务没意义）
|
 |
18
可以理解成单元，微服务就是把系统的拆分单元化，这样将来需要扩容时候，可以轻松知道只需要扩容哪个或者哪几个单元。
举例说：某系统从 100 用户涨到 100000 用户，可能只是某个核心内容节点的读取量上升，那么其实只需要将这个读取内容的单元做负载均衡扩容 |
|
opengpsMar 30, 2019
19
微服务，云架构，都是给将来访问量增加所打下的基础，合理的设计，面对范文压力将来不用推到重新做
|
 |
txwdMar 30, 2019
20
上面的大神说得那么专业，说一下我的理解：就是把功能或模块部署一套或多套，再通过网关串起来。这东西开发成本和维护成本很高，要看场景用。仅是我的理解。
|
 |
edgnozMar 30, 2019
21
对于绝大多数企业来讲，加个云啊微啊什么的，显得高大上
|
 |
willyangMar 30, 2019 via Android
22
划分业务模块的思想吧
|
|
opengpsMar 30, 2019
23
临时写了篇博客，《使用微服务和云架构应对系统扩容》 https://www.opengps.cn/Blog/View.aspx?id=279
结论: 微服务的价值：在于将来访问量上升时，精准调控某一个瓶颈点的功能，主要属于开发层面的储备 云架构的价值：在于访问量上升时，直接增加服务器数量扩大系统承载阈值，主要属于运维层面的储备 |
 |
CyanicMar 30, 2019 via iPhone
24
解耦合从代码层面进化到业务功能模块层面，模块间采用 rpc 通信，这是我的个人理解
|
 |
BCy66drFCvk1Ou87Mar 30, 2019 via Android
25
“分而治之”
|
 |
huijieweiMar 30, 2019
26
微服务容易扩容
看你项目决定 |
 |
27
SOA 老调新弹
|
 |
zzl22100048Mar 30, 2019
28
小而自治，单一职责
|
 |
wc951Mar 30, 2019 via Android
29
去中心化 soa
|
 |
limuyan44Mar 31, 2019 via Android
30
就是功能拆分。。
|
 |
hsuehsenMar 31, 2019
31
1. 原生支持高可用、集群（分布式）、高并发，可根据流量水平扩展
2. 服务拆分，说白了就是解耦 服务之间通过接口的方式提供服务，所以开发、维护成本低。因为就是开发全新的一个子系统，没有历史负担，可以根据团队技术栈，选择全新的语言与开发框架 3. 网关作为入口，可做限流、授权（ api 级别）、分发等，共性的可以都放在网关，容易维护 很多人都说小公司用不用微服务无所谓。只是我的观点恰恰相反，小公司更应该用微服务，因为只要一开始框架搭好，原生就支持高可用、高并发——这就可以省很多事情。 在公司业务扩展的时候，选择技术方案与招人，也可以灵活很多；不需要特定的技术栈 |
Select Language