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